SRE Foundation key terms

A core SRE principle holding that systems cannot be made perfectly reliable at reasonable cost, so teams deliberately choose how much unreliability to accept and spend reliability effort where it matters most.

Estimating future demand and provisioning enough resources, with headroom for failure and growth, so that a service keeps meeting its objectives as load changes without expensive over-provisioning.

A target range for a service level indicator, for example 99.9 percent of requests succeeding over 30 days, that a team commits to and uses to decide when reliability work is needed.

A contract with customers or internal stakeholders stating promised service levels and the consequences of missing them; it is typically looser than the internal objectives a team manages day to day.

The amount of unreliability an objective permits, usually one minus the target expressed over the compliance window, which teams spend on releases and experiments to balance reliability against change.

A pre-agreed written rule describing what happens when the error budget is exhausted or burning too fast, such as pausing risky releases, escalating to leadership, and prioritizing reliability work.

How quickly an error budget is being consumed relative to the pace that would exhaust it exactly at the end of the compliance window; a burn rate of one means spending at the sustainable rate.

The time period over which an objective is measured and judged, such as a rolling 28 days, after which older data stops counting toward the target.

Work that is manual, repetitive, tactical, and devoid of lasting value, tends to grow as a service scales, and could often be automated or eliminated rather than repeated by engineers.

A guideline limiting each SRE to spending no more than about half of their time on toil, with the remainder reserved for engineering work that permanently reduces operational burden.

A step-by-step documented procedure for handling a known operational task or alert, written so any on-call engineer can act correctly without deep knowledge of the system's internals.

Using software to perform operational tasks that would otherwise be done by hand, ideally making the action repeatable, consistent, and fast enough to remove the need for human intervention.

Managing systems, infrastructure, and their settings through version-controlled machine-readable files rather than manual changes, so changes can be reviewed, tested, repeated, and rolled back.

Deploying a change to a small subset of traffic or machines first, watching service indicators for problems, and only then widening the rollout to everyone.

Practices that automatically build, test, and deliver code changes through a pipeline, so software reaches production frequently and in small, reversible increments rather than rare large releases.

A structured check before a service takes real traffic, covering reliability requirements such as objectives, monitoring, capacity, failure handling, and ownership, so gaps are fixed before users are affected.

Collecting and presenting predefined metrics and health signals from running systems so operators can see whether services are working and can be paged when known bad conditions appear.

A quantitative measure of some aspect of service behavior, such as request success rate or latency, computed from monitored data and used as the raw input for judging whether users are served acceptably.

The degree to which the internal state of a system can be inferred from its outputs, such as logs, metrics, and traces, allowing engineers to answer new questions without shipping new code.

The four service signals recommended for monitoring: latency, traffic, errors, and saturation, which together give a quick view of user-facing health and impending capacity problems.

The loss of responsiveness that occurs when people receive too many low-value or noisy alerts, causing real incidents to be missed, delayed, or ignored.

Recording the path of a single request as it passes through many services, with timing per hop, so engineers can find where latency or errors originate in a complex system.

Paging on error budget consumption, for example when burn rate is high over both short and long windows, rather than on raw thresholds, so alerts reflect user impact and stay quiet when nothing is wrong.

A written review after an incident that records the timeline, impact, contributing factors, and follow-up actions, aimed at improving systems and shared understanding rather than assigning blame.

A way of working in which people are assumed to have acted reasonably given the information they had, so incidents are analyzed for systemic causes and honest reporting is not punished.

A team climate where people can raise concerns, admit mistakes, and ask questions without fear of humiliation or punishment, which supports fast learning from failure.

Deliberately introducing controlled failures, such as killing instances or adding latency, in a safe experiment to reveal weaknesses in a system before they cause real outages.

Planned exercises that simulate major failures or site loss to verify that backups, failover, and recovery procedures actually work within the promised time and data-loss limits.

A bounded part of a system that fails as a unit, such as a single machine, rack, zone, or region; designing across such boundaries keeps one failure from taking down everything.

A property of a system that improves under stress and disorder, because it learns from and adapts to failures rather than merely surviving them or being damaged by them.

The average time taken to restore service after an incident begins, a key measure of how well a team detects, diagnoses, and mitigates failures.

A schedule in which engineers take turns being the first responder for alerts, with clear escalation paths and handoffs, so production problems are always owned by someone reachable.

An engagement model where SRE engineers join a product team for a period, sharing reliability practices and building capabilities inside that team rather than owning operations from outside.

A movement and set of practices that unify software development and operations through shared ownership, automation, and fast feedback, aiming to deliver changes quickly and safely.

A widely used framework of IT service management practices covering incident, problem, and change management, which overlaps with SRE in places but takes a broader process-oriented view.

An approach from manufacturing focused on removing waste, limiting work in progress, and improving flow continuously, which informs SRE efforts to cut toil and shorten recovery time.

Building internal self-service platforms and tooling so product teams can deploy and operate services safely without deep infrastructure expertise or tickets to a central operations group.

Applying machine learning and analytics to operational data to detect anomalies, correlate events, and suggest or automate remediation, an emerging direction for reducing manual monitoring effort.