SRE glossary: reliability terms in plain English

Acknowledge: Confirming that a person has seen an alert and is working on it. Our contract sets this at 15 minutes for every alert.
Alert fatigue: When people get so many alerts that they start missing or delaying the important ones. Alerts guide.
Burn rate: How fast a service is using up its error budget. A burn rate of 1 uses the budget up exactly at the end of the period; higher means faster. Alerts guide.
Contributing factors: The several conditions that together let an incident happen, such as a missing test, an alert that never fired and a release that went everywhere at once. Most incidents have more than one. Incident reports guide.
Critical user journey: An end-to-end task users care about, such as signing up or paying. Measuring the whole journey catches failures that backend numbers miss. Reliability targets guide.
Error budget: The amount of failure a reliability target allows. A target of 99.9% over 30 days leaves about 43 minutes of failure. While budget remains you can take risks; when it runs out, stability comes first. Reliability targets guide.
Escalation: Handing an issue to someone with more context or authority. With us, anything without an approved runbook goes to your on-call engineer with the evidence.
Follow-the-sun: Splitting on-call between teams in different time zones, so each covers its own daytime and nobody works through the night. On-call guide.
Generic mitigation: A fix that is safe to apply before you know the cause: roll back, move traffic away, add capacity, switch off a non-essential feature, or block a request that crashes servers. Runbooks guide.
Graceful degradation: Keeping the core of a service working under strain by switching off less important features first. Capacity guide.
Heartbeat alert: An alert that fires when expected signals stop arriving, so a broken monitoring pipeline doesn’t look like a quiet night. Sometimes called a dead man’s switch. Alerts guide.
Incident: Anything suggesting users are having a bad experience, or that one is about to happen. Not every incident is an outage.
Incident report (postmortem): A written review after an incident: the timeline, who was affected, the contributing factors, what went well and the follow-up actions, written without blame. Incident reports guide.
Instrumentation: Code in your services that reports what they’re doing as metrics, logs and traces. Usually added with OpenTelemetry, an open standard most monitoring tools accept. Observability guide.
Least privilege: Giving each person or system only the access it needs, for only as long as it needs it. Security and access.
Likely cause: The best-supported explanation for an alert at the time of triage, with the evidence behind it. Our monthly report shows how often our first likely cause matched the cause confirmed at close.
Load shedding: Deliberately turning away lower-priority work when demand exceeds capacity, so the most important requests still succeed. Capacity guide.
Mitigation: Stopping or reducing the harm to users. It often comes before anyone fully understands the cause.
Near miss: Something that could have caused an incident but was caught in time. Near misses show which defences are doing the work. Incident reports guide.
Observability: Being able to ask your systems new questions during an incident, using metrics, logs and traces together, without already knowing them inside out. Monitoring tells you something is wrong; observability helps you find why. Observability guide.
On-call: Being the named person who responds to alerts for a set period, including out of hours. On-call guide.
Outage: When a service or a critical feature can’t do its job.
Primary and secondary: Two people on each on-call shift: if the primary doesn’t acknowledge a page, it moves to the secondary automatically. On-call guide.
Reliability target (SLO): A target for how a service should perform, such as 99.9% of checkouts succeeding over 30 days. SLO stands for service level objective. The business should set it. Reliability targets guide.
Rollback: Returning to the previous working version after a bad release. Only dependable if it has been tried before you need it. Runbooks guide.
RPO (recovery point objective): How much recent data you can afford to lose, measured in time. Backups guide.
RTO (recovery or restore time objective): How long a restore may take, from noticing the problem to working again. Backups guide.
Runbook: A written, step-by-step fix for a known problem, clear enough for someone woken at 2am to follow. With us, a runbook runs only if you’ve approved it. Runbooks guide.
Service charter: The one-page agreement we make before cover starts: which services we cover and how, what’s out of scope, and how success is measured.
SLA (service level agreement): A contract term saying what happens, often a penalty, when a promised level of service is missed. Different from an SLO, which is an internal target.
SLI (service level indicator): The measurement behind a reliability target, usually good events divided by total events, such as successful checkouts out of all attempts.
SRE (site reliability engineering): Treating the job of keeping production running as an engineering problem: measuring reliability, automating repetitive work and learning from incidents as well as answering alerts.
Synthetic check: A scripted test that walks through a user journey every few minutes, so you find out it’s broken before your users do. Reliability targets guide.
Toil: Manual, repetitive operational work that grows with your system and leaves nothing lasting behind. SRE teams aim to keep it well under half their time.
Trace: The path one request takes across your services, with the time spent at each step, so you can see where a slow or failed request went wrong. Observability guide.
Triage: Working out how serious an alert is, who is affected and who needs to be involved. Triage is not fixing. Our contract sets 30 minutes for cause and severity.

SRE terms, in plain English.

You build the product. Our engineers stay on call.