Customer Reliability Engineering English: SLAs, SLOs, and Customer-Facing Reliability Vocabulary
Master the English vocabulary SRE teams use to talk about reliability commitments, incident communication, and customer-facing status updates.
When an outage hits at 2 a.m. and customers are asking questions, your English needs to be fast, clear, and precise. Customer-facing reliability work demands a specific vocabulary — one that bridges technical reality and business communication. This post covers the core terms SRE and platform teams use when talking to customers, writing status pages, and running postmortems.
Core Reliability Agreement Terms
SLA (Service Level Agreement) — a formal, often legally binding contract between a service provider and a customer that specifies the expected level of service, including uptime guarantees and penalties for missing them.
“Our enterprise SLA guarantees 99.9% monthly uptime. If we breach it, customers receive service credits automatically.”
SLO (Service Level Objective) — an internal target for a specific reliability metric, usually stricter than the SLA. Teams use SLOs to catch problems before they become SLA violations.
“We set our SLO at 99.95% so we have a buffer before we hit the 99.9% SLA threshold.”
SLI (Service Level Indicator) — the actual measured metric used to evaluate whether an SLO is being met. Common SLIs include request latency, error rate, and availability.
“Our primary SLI for the checkout service is the percentage of requests completing in under 500ms.”
Error budget — the amount of unreliability a service is allowed to have within a given period while still meeting its SLO. When the error budget is exhausted, teams typically freeze new feature releases.
“We’ve burned through 80% of our monthly error budget in the first two weeks — no new deploys until the 1st.”
MTTR (Mean Time to Recovery) — the average time it takes to restore a service after an incident begins. A lower MTTR indicates a more resilient and operationally mature team.
“After we automated our rollback process, our MTTR dropped from 45 minutes to under 8 minutes.”
MTTA (Mean Time to Acknowledge) — the average time between an alert firing and a team member confirming they are investigating it.
“PagerDuty shows our MTTA spiked last week — we need to review our on-call rotation.”
Incident Communication Terms
Incident communication — the practice of keeping stakeholders and customers informed during an active outage, using clear, non-technical language and regular status cadence.
“During the incident, we sent customer-facing updates every 30 minutes even when we had nothing new to report — silence makes customers anxious.”
Customer-facing status page — a public webpage (often on a separate domain) that shows real-time service health and incident updates. Statuspage.io and Atlassian Status are common tools.
“Update the status page before you post in Slack — customers check it before they email support.”
Business impact statement — a short, plain-English description of how an incident affects customers and their workflows, used in external communications and executive briefings.
“Avoid technical jargon in the business impact statement. Instead of ‘pod eviction storm,’ write ‘some users were unable to log in for approximately 12 minutes.’”
RCA (Root Cause Analysis) — a structured investigation into why an incident occurred, focused on identifying underlying system or process failures rather than assigning individual blame.
“The RCA revealed that the incident was triggered by a config change that bypassed our staging environment review.”
Postmortem — a written document produced after an incident, combining timeline, RCA, business impact, and action items. Blameless postmortems are the industry standard.
“The postmortem is due Friday — make sure the action items have owners and deadlines, not just vague descriptions.”
Real IT Context Phrases
These phrases appear regularly in customer reliability work. Study them as complete units:
- “We are currently investigating an issue affecting…” — the standard opening for a status page incident update
- “This incident has been resolved. We apologize for any inconvenience.” — the closing statement after recovery
- “No customer data was affected during this incident.” — a critical reassurance phrase in security-adjacent incidents
- “We will publish a full postmortem within 5 business days.” — a commitment phrase used in enterprise incident closures
- “The root cause was a misconfigured load balancer rule introduced during the maintenance window.” — example of a precise, non-blaming RCA sentence structure
Key Collocations
Learn these as fixed phrases — they are used almost exactly this way in professional SRE writing:
| Collocation | Usage |
|---|---|
| burn the error budget | ”We burned the error budget with that botched migration.” |
| breach an SLA | ”Three incidents in one week — we’re at risk of breaching the SLA.” |
| declare an incident | ”The on-call engineer declared an incident at 03:47 UTC.” |
| publish a postmortem | ”We always publish postmortems publicly to build customer trust.” |
| restore service | ”Service was fully restored by 14:22 UTC.” |
| customer-facing impact | ”Quantify the customer-facing impact before the exec briefing.” |
| miss the SLO | ”We missed the SLO in March due to the CDN provider outage.” |
Writing Clear Customer Updates
One of the hardest English skills in SRE work is translating technical findings into customer language. Follow this pattern:
- What is happening (in plain terms, no jargon)
- Who is affected (all users / users in region X / users using feature Y)
- What you are doing (investigating / implementing a fix / monitoring)
- When you will update next (specific time, not “soon”)
Bad: “Experiencing elevated p99 latency due to pod scheduling backpressure on node pool eu-west-2c.”
Good: “Some users may experience slow loading times. Our team is actively investigating and will provide an update by 15:00 UTC.”
Practice
Take the last incident or near-miss at your company and write a 3-paragraph postmortem executive summary in English. Include: a business impact statement (one sentence), the root cause (one sentence), and three action items with owners. Aim for zero technical acronyms in the first paragraph — the audience is a non-technical VP. Share it with a colleague for feedback on clarity.
Mastering the SRE Vocabulary – Beyond the Basics
SRE teams don’t just fix things; they actively manage risk, communicate clearly, and demonstrate a commitment to service levels. But translating that into effective English can be tricky, especially when dealing with complex technical concepts and customer expectations. This section focuses on refining your vocabulary beyond simple descriptions, helping you articulate the nuances of SRE practices – crucial for building trust and demonstrating accountability. It’s about moving from simply stating what happened to explaining why, outlining how it impacted customers, and proactively setting realistic expectations. Think not just “the server crashed,” but “a sustained network latency event degraded user experience impacting key workflows.” This shift in phrasing is vital for collaborative problem-solving and transparent communication.
A common hurdle is understanding the difference between SLAs (Service Level Agreements) and SLOs (Service Level Objectives). An SLA is a contract, typically legally binding, outlining what you promise to deliver. It’s often broad and focuses on specific metrics, frequently measured against a fixed threshold. Conversely, an SLO is a target – an internal goal based on data analysis that guides development and operational decisions. It’s more flexible and dynamic, allowing for adjustments based on real-time performance. Using the correct terminology demonstrates a sophisticated understanding of risk management: “We’re operating under our 99.9% SLO for API response time, which allows for a small buffer to account for anticipated peak loads.”
Another key area is customer-facing communication. Instead of vague statements like “we’re working on it,” SREs use precise language that conveys both the issue and its impact. A good example might be in a Slack message: “@customer, experiencing intermittent high latency on the reporting dashboard due to a database query optimization task. We’ve identified the root cause – inefficient indexing – and are deploying an update expected within 30 minutes. This will directly improve your report generation speed.” Notice the specific details - the affected area, the identified cause, and the estimated resolution time.
Finally, remember that measurement is key to effective communication. Sharing data transparently demonstrates a commitment to continuous improvement. Let’s look at a simple CLI example using kubectl – illustrating how monitoring metrics informs reporting:
kubectl top nodes --sort=-cpu # Retrieve CPU usage for all nodes and sort descending by CPUThis command, combined with the data it provides, allows you to say something like, “Node ‘titan’ is currently experiencing high CPU utilization (85%), impacting its ability to serve requests. We’re investigating potential causes and implementing scaling adjustments.” The CLI isn’t just a tool; it’s evidence of proactive monitoring and data-driven decision making – a powerful element in communicating reliability.