50 Performance Review Phrases for Site Reliability Engineers

This page collects 50 performance review phrases written for the day-to-day realities of a Site Reliability Engineer role, covering self assessments, peer feedback, and manager reviews. Swap in your own systems, incidents, and metrics where a placeholder appears, and adjust the tone to fit your organisation's style.

Self assessment phrases - achievements

I improved the reliability of [service] by identifying and fixing recurring failure points.
I led the response to an incident involving [system], diagnosing the root cause and restoring service quickly.
I built monitoring and alerting for [service] that caught issues before they affected users.
I wrote a postmortem for [incident] that led to real changes in how the team handled that class of failure.
I automated a manual runbook step, which reduced the time it took to resolve a recurring issue.
I set clear service level objectives for [service] that gave the team a shared definition of acceptable reliability.
I reduced our on-call burden by fixing the root cause of a recurring page instead of just responding to it each time.
I partnered with [team] to make their service more resilient before it caused a bigger incident.
I improved our capacity planning for [system], catching a scaling issue before it became urgent.
I mentored [engineer] through their first on-call rotation, helping them build confidence handling incidents.

Self assessment phrases - growth and development

I want to get better at writing postmortems that lead to concrete action items, not just a narrative of what happened.
I'm working on documenting systems as I build them instead of after the fact.
I sometimes chase a root cause further than the incident's severity warrants, and I'm learning to judge that better.
I'd like to build stronger skills in [technology or tool] so I can support more of our infrastructure directly.
I want to get more comfortable pushing back on a launch that would add operational risk without enough benefit.
I'm learning to prioritise reliability work against feature requests when both compete for my time.
I could do more to communicate the operational impact of a design decision earlier in the process.
I want to improve how I communicate during an incident so people outside the team understand what's happening.
I'm working on writing runbooks that are clear enough for someone unfamiliar with the system to follow during an incident.
I'd like to spend more time on proactive reliability work instead of only responding to pages as they come in.

Peer review phrases

They're one of the people I go to first when a service isn't behaving as expected.
They write clear, blameless postmortems that focus on the system rather than who was on call.
They're calm and methodical during an incident, even when the cause isn't obvious.
They flagged a reliability risk in [system] that the rest of us hadn't considered.
They're generous with their time when helping other engineers understand our infrastructure.
They think about the operational cost of a design, not just whether it works.
They automate the repetitive parts of on-call work, which frees up time for harder problems.
They're honest about the tradeoffs of a reliability decision instead of overselling it.
They've become someone the team relies on for questions about [system or platform area].
They respond to incidents quickly and communicate clearly while they work through them.

Manager review phrases - strengths

They consistently improve the reliability of the services they own.
They have a good instinct for when a design needs more resilience before it goes into production.
They communicate clearly during incidents, which keeps stakeholders informed without adding noise.
They've taken ownership of [system or service] and its reliability has improved as a result.
They write postmortems that lead to real changes, not just documentation of what happened.
They stay calm and methodical during incidents, even under pressure.
They're dependable with on-call responsibilities and rarely need reminders about escalation procedures.
They've grown noticeably in their ability to handle complex incidents over the past review period.
They think about the long-term reliability of a system, not just whether it works today.
They've become a go-to resource for the team on [technology or platform area].

Manager review phrases - areas to develop

I'd like to see them document systems as they build them rather than after the fact.
They sometimes chase a root cause further than the incident's severity warrants, and could scale their effort accordingly.
I'd encourage them to flag operational risk earlier in the design process, before launch is imminent.
Their postmortems would benefit from more concrete action items, not just a narrative of what happened.
I'd like to see them push back more when a launch adds operational risk without enough benefit.
They could be more proactive about capacity planning before a scaling issue becomes urgent.
I'd like them to build more confidence presenting reliability tradeoffs to non-technical stakeholders.
Their technical work is strong, and I'd like to see them build more comfort mentoring newer engineers through on-call.
I'd encourage them to take more ownership of [specific system or process] rather than waiting for direction.
They tend to react to pages rather than doing proactive reliability work, and could build in more regular reviews.

Want phrases tailored to your exact role and focus area? Use the free AI phrase generator, or draft a complete review free.