Reference Updated 27 Oct 2026

SRE glossary

Short, precise definitions of the terms that come up in reliability work, linked to longer guides where they exist.

Availability · Blameless postmortem · Blast radius · Burn rate · Canary release · Capacity planning · Change freeze · Chaos engineering · Circuit breaker · Error budget · Error budget policy · Escalation policy · Failover · Feature flag · Four golden signals · Game day · Graceful degradation · Incident · Incident commander · Load shedding · MTBF · MTTA · MTTD · MTTR · Multiwindow, multi-burn-rate alert · Nines · Observability · On-call · Percentile (p50, p99) · Postmortem · RED method · Rollback · Rolling window · RPO · RTO · Runbook · Saturation · Severity · SLA · SLI · SLO · SPOF · SRE · Status page · Synthetic monitoring · Thundering herd · Toil · USE method

Availability: The share of time, or of valid requests, in which a service works as intended. Often written in “nines”; see the availability table.
Blameless postmortem: A written review of an incident that focuses on contributing conditions in systems and processes rather than on individual fault. See the postmortem template.
Blast radius: How much of the system or user base a failure or change can affect. Cells, regions, canaries and feature flags limit it.
Burn rate: How fast an error budget is being spent relative to the rate that would exactly exhaust it at the end of the SLO window: error rate ÷ (1 − SLO). See burn-rate alerting.
Canary release: Rolling a change out to a small share of traffic or hosts first and comparing its behaviour against the existing version before continuing.
Capacity planning: Forecasting demand and provisioning enough resources, with headroom, to meet SLOs as traffic grows and during failures.
Change freeze: A period in which non-essential production changes are halted, for example when the error budget is exhausted or during a peak event.
Chaos engineering: Running controlled experiments that inject real-world failures, such as killed instances or added latency, to test a hypothesis that a measurable steady state holds, with the blast radius kept small. It aims to find weaknesses, not to confirm resilience.
Circuit breaker: A client-side pattern that stops calling a failing dependency for a while after repeated errors, so failures do not cascade.
Error budget: The amount of unreliability an SLO allows in its window: 1 − SLO. A 99.9% SLO has a 0.1% budget. See the calculator.
Error budget policy: An agreement on what the team does when the error budget is spent, such as freezing releases. See error budget policy.
Escalation policy: The ordered list of people or teams to notify, with timeouts, when a page is not acknowledged.
Failover: Switching traffic or work from a failed component to a standby or replica.
Feature flag: A runtime switch that enables or disables functionality without a deploy, useful for gradual rollout and fast mitigation.
Four golden signals: Latency, traffic, errors and saturation: the core service metrics from Google’s SRE book. See golden signals, RED and USE.
Game day: A planned exercise in which a team simulates a failure or incident to practise response and test assumptions.
Graceful degradation: Continuing to serve a reduced but useful experience when a dependency or resource fails, instead of failing completely.
Incident: An unplanned event that disrupts or threatens a service and needs a coordinated response. See incident severity levels.
Incident commander: The person who coordinates an incident response: sets priorities, assigns work and owns communication decisions, without doing the hands-on debugging.
Load shedding: Deliberately rejecting some requests when overloaded so that the rest can still be served within their objectives.
MTBF: Mean time between failures: average operating time between one failure and the next.
MTTA: Mean time to acknowledge: average time from an alert firing to a responder acknowledging it.
MTTD: Mean time to detect: average time from the start of an incident to its detection.
MTTR: Mean time to repair, recover, restore, resolve or respond, depending on who is speaking. Always say which. Averages of incident durations are noisy and easy to game, so treat MTTR as a rough trend rather than a target.
Multiwindow, multi-burn-rate alert: An SLO alert that fires when the error budget burns faster than a threshold over both a long and a short window, with several thresholds for paging and ticketing. See burn-rate alerting.
Nines: Shorthand for availability: “three nines” is 99.9%, “four nines” 99.99%. Each extra nine allows one tenth of the downtime.
Observability: How well you can understand a system’s internal state from its outputs, typically metrics, logs and traces, including for questions you did not anticipate.
On-call: Being available to respond to production alerts within an agreed time. See on-call basics.
Percentile (p50, p99): The value below which a given share of observations fall. p99 latency of 400 ms means 99% of requests took 400 ms or less. Percentiles cannot be averaged across instances.
Postmortem: See blameless postmortem.
RED method: Rate, errors and duration: three per-service metrics for request-driven services. See golden signals, RED and USE.
Rollback: Returning a service to a previous known-good version or configuration, usually the fastest mitigation for a bad change.
Rolling window: An SLO window that always covers the most recent period, such as the last 28 days, as opposed to a calendar month.
RPO: Recovery point objective: the maximum acceptable data loss, measured in time, after a failure. See RTO vs RPO.
RTO: Recovery time objective: the maximum acceptable time to restore service after a failure. See RTO vs RPO.
Runbook: Step-by-step instructions for diagnosing and mitigating a known alert or task. Also called a playbook. See the runbook template.
Saturation: Two related meanings. As a golden signal, how full a service is, measured by its most constrained resource. In the USE method, the extra work a resource cannot serve yet, usually queued; distinct from utilisation, which is how busy it is.
Severity: A classification of an incident by impact (for example SEV1 to SEV4) that determines the response. See incident severity levels.
SLA: Service level agreement: a contract that promises a service level and specifies consequences, such as credits, for missing it. See SLI vs SLO vs SLA.
SLI: Service level indicator: a measurement of service behaviour, usually good events ÷ valid events. See SLI vs SLO vs SLA.
SLO: Service level objective: a target value for an SLI over a time window, such as 99.9% of requests succeeding over 30 days. See SLI vs SLO vs SLA.
SPOF: Single point of failure: a component whose failure alone takes the service down.
SRE: Site reliability engineering: applying software engineering to operations, with reliability targets, error budgets and automation. Also the people who do it.
Status page: A public or internal page that reports service health and incident updates to users.
Synthetic monitoring: Probing a service with scripted requests from outside to measure availability and latency as a user would see it.
Thundering herd: Many clients retrying or reconnecting at the same moment, often after an outage, overwhelming the recovering system. Mitigated by exponential backoff with jitter.
Toil: Manual, repetitive, automatable operational work with no enduring value that scales with the service. See toil.
USE method: Utilization, saturation and errors: a checklist for analysing every resource in a system. See golden signals, RED and USE.

Sources: Google, Site Reliability Engineering and The Site Reliability Workbook (SLI, SLO, SLA, error budget, burn rate, toil, golden signals, on-call, postmortems); Brendan Gregg, “The USE Method”; Tom Wilkie’s RED method as reported by Grafana Labs; Principles of Chaos Engineering.