English for Platform Reliability Reviews: Phrases SREs Actually Use
Learn the English vocabulary and phrases for SRE reliability reviews: SLOs, error budgets, blameless framing, and confident ways to present and challenge data.
Reliability reviews are recurring meetings where Site Reliability Engineers (SREs) and product teams examine how a service performed against its targets. The language is precise, slightly formal, and heavy with shared vocabulary. If you are a non-native speaker, the hardest part is not the technical content — it’s sounding confident while staying diplomatic. This guide gives you the exact phrases.
Core vocabulary you must own
| Term | What it means | Used in a sentence |
|---|---|---|
| SLO (Service Level Objective) | The target you commit to | ”We set our SLO at 99.9% availability.” |
| SLI (Service Level Indicator) | The metric you measure | ”Our latency SLI breached the threshold twice.” |
| Error budget | Allowed amount of failure | ”We’ve burned 80% of our error budget this quarter.” |
| Burn rate | Speed of consuming the budget | ”The burn rate spiked during the deploy.” |
| Toil | Repetitive manual operational work | ”We’re trying to reduce toil through automation.” |
| Blast radius | Scope of impact of a failure | ”The blast radius was limited to one region.” |
Notice how error budget collocates with verbs like burn, consume, exhaust, and spend. Native speakers say “we burned through our budget,” not “we used our budget badly.”
Opening the review
A reliability review usually starts with a status summary. Keep it factual and neutral.
“This quarter, the checkout service met its availability SLO but fell short on latency. We were inside budget for three of the four months.”
Useful openers:
- “Let me walk you through the numbers for this period.”
- “At a high level, we’re trending in the right direction.”
- “There are two areas I want to flag today.”
Avoid dramatic language. Say “latency degraded” rather than “everything was terrible.” Reliability culture values calm precision.
Presenting data with confidence
When you show a graph or dashboard, narrate it. Don’t just say “as you can see.”
“If you look at the p99 latency, it climbed from 180 milliseconds to over 400 around the 14th. That correlates with the traffic surge we saw after the marketing campaign.”
Key verbs for describing trends:
- climbed / rose / spiked / surged — went up
- dropped / fell / declined / dipped — went down
- plateaued / held steady / flattened out — stayed the same
- recovered / normalised / stabilised — returned to normal
“Latency spiked at noon, plateaued for an hour, then recovered once we scaled out.”
Use correlate with (not “is connected to”) and be attributable to for cause:
“The increase is largely attributable to a slow downstream dependency.”
Challenging a number politely
Sometimes you disagree with how a metric is being interpreted. Soften the disagreement so it lands as collaboration, not confrontation.
| Direct (risky) | Diplomatic (better) |
|---|---|
| “That number is wrong." | "I’m not sure that figure tells the full story." |
| "You measured it badly." | "I wonder if the measurement window is skewing this." |
| "That’s not the real cause." | "I’d push back gently on that being the root cause.” |
“I’d push back gently here — the p50 looks healthy, but the p99 suggests a tail-latency problem we’re masking with the average.”
The phrase push back is essential SRE vocabulary. It means to challenge or resist a claim. “Push back gently” or “push back a little” keeps it polite.
Talking about the error budget policy
Error budgets drive decisions: when the budget is healthy, you ship features; when it’s exhausted, you freeze releases and focus on reliability.
“We’ve exhausted our error budget for the quarter, so per our policy we should freeze feature work and prioritise stability.”
“We still have headroom in the budget, so I’m comfortable approving this risky migration.”
Headroom means remaining capacity or margin — a very useful, natural word.
Blameless framing
Reliability reviews are blameless: you discuss systems and processes, not people. The grammar matters. Use the passive voice or “the system” as the subject, not “you.”
| Blameful | Blameless |
|---|---|
| ”You forgot to add the alert." | "An alert wasn’t configured for that path." |
| "Dev broke the deploy." | "The deploy introduced a regression." |
| "Why didn’t anyone notice?" | "What signals could have surfaced this earlier?” |
“The incident surfaced a gap in our alerting. The question isn’t who missed it — it’s how do we make it visible next time.”
Before and after: a full rewrite
Before (non-native, blunt):
“Our service was very bad last month. The latency was high and you must fix the database because it is slow and it is your fault.”
After (clear, professional, blameless):
“Last month the service fell short of its latency SLO. The p99 climbed sharply, and that’s largely attributable to contention on the primary database. I’d suggest we prioritise the read-replica work next sprint to claw back some headroom.”
The phrase claw back (recover something lost) is idiomatic and impressive when used correctly.
Closing the review and assigning actions
End with clear ownership. Vague endings waste reviews.
- “So the action item here is to tune the connection pool — can you take that on?”
- “Let’s circle back on the alerting gap next week.”
- “I’ll own the runbook update and report back by Friday.”
“To wrap up: budget is healthy, two action items, owners assigned. Thanks everyone.”
Common mistakes to avoid
- Saying “the service is down” when you mean “degraded.” Down means fully unavailable; degraded means working but worse. Mixing these alarms people.
- Overusing “maybe” and “I think.” One hedge per sentence is plenty. “Maybe I think possibly we could perhaps look at it” destroys your credibility.
- Translating “actual” as “current.” In English, actual means real/true, not now. Say “the current latency,” not “the actual latency,” when you mean now.
Key takeaways
- Master the collocations: burn an error budget, push back on a claim, have headroom in the budget.
- Describe trends with precise verbs (spiked, plateaued, recovered) and link causes with attributable to.
- Keep every sentence blameless — make the system the subject, not the person.
- Soften disagreement with “I’d push back gently” and close with clear action items and owners.
Reliability reviews reward calm, specific English. Practise these phrases out loud before your next one, and you’ll sound like an SRE who’s been doing this for years.
Navigating Nuance: Common Pitfalls for Non-Native Speakers
Many developers transitioning into roles involving platform reliability, particularly those whose first language isn’t English, find the specific terminology and communication styles challenging. It’s not simply about knowing the definitions of terms like “SLO” or “error budget”; it’s about understanding how they’re used in context and building a natural flow when discussing complex technical issues. One frequent hurdle is subtle differences in phrasing that can dramatically alter the perceived tone – moving from collaborative to accusatory, for example. Recognizing these nuances early on is crucial for effective participation in reviews and contributing meaningfully to the team’s success.
Specifically, there’s a tendency among some newcomers to overly formalize their language when discussing problems. Phrases like “The root cause analysis indicates…” can sound stiff and detached, especially during a heated discussion about an outage. Instead, aiming for a more conversational, yet precise, approach is generally better received. It’s also important to be aware of how directness is perceived – what might be considered straightforward in one culture could be interpreted as blunt or even disrespectful in another. Focusing on impact rather than assigning blame is key; framing issues around the user experience and system health will always resonate more positively than dwelling on individual actions.
Another area needing attention is understanding the use of qualifiers. Phrases like “potentially” or “might” can often be interpreted as hedging responsibility, which isn’t necessarily a negative thing, but it needs to be used strategically. Saying “This could have been prevented by…” is far less constructive than “Let’s explore how we could have proactively detected this situation.” Similarly, when presenting data – whether in a slide deck or during a discussion – avoid overly technical jargon that might obscure the core message for those unfamiliar with the underlying systems. Keep explanations concise and focused on the what and why, rather than getting bogged down in the how.
Finally, remember that active listening is just as important as clear articulation. Pay close attention to non-verbal cues – body language, tone of voice – alongside the words being spoken. Asking clarifying questions (“Could you elaborate on what you mean by…?” or “Can you give me an example of that?”) demonstrates engagement and a genuine desire to understand the perspective of others, fostering a more productive dialogue. Don’t hesitate to politely request clarification if something isn’t immediately clear – it’s far better to ask than to proceed based on assumptions.