Site Reliability Engineering (SRE) is the practice of applying software engineering to the operation of production services. It gives teams a structured way to set reliability goals, measure user-visible behavior, respond to failures, and replace repetitive operational work with durable engineering.
SRE can describe a discipline, an operating model, a job role, or a dedicated team. The label matters less than the behavior: service owners agree on what reliable means, use evidence to balance reliability with delivery speed, and improve the system after incidents instead of accepting recurring manual work.
What does SRE mean?
SRE stands for Site Reliability Engineering. A site reliability engineer combines software engineering and systems knowledge to keep a service available, responsive, efficient, and safe to change throughout its lifecycle.
Google's original definition is deliberately concrete: SRE is what happens when a software engineer designs an operations team. Ben Treynor Sloss describes joining Google in 2003 to run a seven-engineer production team and building the group around software-based solutions to operational problems in Google's introduction to Site Reliability Engineering. That is the documented origin of the name, not a staffing template that every organization must copy.
The broader idea is not specific to Google or to websites. SRE practices can apply to an API, data pipeline, internal developer service, mobile backend, payment system, or any other software service whose reliability affects users. An organization does not need Google-scale infrastructure or a team called “SRE” to use the model.
SRE is more than keeping servers online
Infrastructure availability is only one part of reliability. A service may have healthy hosts while users receive errors, slow responses, stale results, or incomplete data. SRE therefore starts with the service behavior that users need, then connects that behavior to engineering and operational decisions.
Google's foundational SRE text assigns the discipline responsibility for availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning. The exact ownership varies by organization, but the common theme is end-to-end service reliability rather than a narrow server-administration queue.
An SRE operating model normally includes:
- measurable reliability objectives based on important user journeys;
- monitoring and alerts that lead to a timely human action;
- safe change, deployment, and recovery mechanisms;
- clear incident roles, communication, and decision records;
- learning from failures without assigning personal blame;
- capacity and dependency planning;
- automation that reduces repetitive operational work; and
- shared responsibility between service developers and operators.
How SLIs, SLOs, and error budgets work
SLIs, SLOs, and error budgets turn “make it reliable” into a measurable policy. They are related, but they are not interchangeable.
An SLI, or service level indicator, is a measurement of service behavior. A useful request-based SLI often takes the form:
good eligible events / total eligible events
For an API, “good” could mean requests that return an expected result within a latency threshold. The numerator and denominator must come from the same observation boundary and event population. CPU usage can help diagnose a failure, but it usually does not describe whether the user's request succeeded.
An SLO, or service level objective, is the target for an SLI over a defined compliance period. For example: “99.9% of eligible checkout requests complete successfully within 500 milliseconds over a rolling 28-day period.” The service boundary, eligible requests, success condition, latency threshold, and period all need explicit definitions.
An SLA, or service level agreement, is an explicit or implicit agreement with users that includes consequences when its commitments are met or missed. Those consequences are often financial, such as credits or penalties, but can take other forms. An internal SLO can be stricter than an SLA so the team has time to act before breaching the external commitment. The separate guide to service level objectives covers these definitions and calculation choices in more depth.
Google's SLO implementation guidance recommends ratio-based SLIs because they make the measurement and budget explicit. It also says stakeholders must agree that the SLO represents the product and can be defended without excessive toil or burnout; see Implementing SLOs.
Error-budget math uses the same population
The error budget is the amount of unreliability permitted by an SLO:
error budget = 1 - SLO target
Suppose an API has a 99.9% request-success SLO and handles 2,000,000 eligible requests during its compliance period:
allowed bad-event ratio = 1 - 0.999 = 0.001
allowed bad requests = 2,000,000 × 0.001 = 2,000
If 500 eligible requests are bad, the service has consumed 25% of that request-based budget. Do not convert those requests into downtime minutes: time-based availability and request-based success are different measurements.
The budget is not a target number of failures and not permission to cause an outage. It is a decision mechanism for balancing change risk with reliability work. When budget burn accelerates or the service exhausts its budget, a written policy can require extra review, safer rollout controls, a pause on selected changes, or prioritized reliability work. Google's example error-budget policy explicitly frames such action as protection for users and permission to focus on reliability, not punishment.
Targets should reflect user needs, product risk, and what the team can measure accurately. A default target of 100% usually removes room for learning and change while still failing to represent dependencies outside the service's control. An objective is useful only when it changes decisions; a dashboard number with no agreed owner or response policy is merely reporting.
What does a site reliability engineer do?
A site reliability engineer makes reliable operation an engineering problem. The work varies by service and team model, but it should combine reactive service ownership with proactive improvements that reduce future operational load.
Define reliability and production readiness
SREs work with product and development teams to identify critical user journeys, define SLIs, set SLOs, and agree on error-budget actions. Before taking on a service or launch, they may review dependency behavior, capacity assumptions, rollback paths, monitoring coverage, access controls, and operational ownership.
A production-readiness review should expose assumptions rather than become a ceremonial checklist. It should answer questions such as:
- Who owns the service and its dependencies?
- Which user journeys must remain reliable?
- How will the team detect and verify customer impact?
- What happens when a dependency is slow, unavailable, or returns bad data?
- Can a change be limited, stopped, or reversed safely?
- Is there enough capacity for expected demand and a defined overload behavior?
- Which actions are safe for an on-call engineer, and which require additional approval?
Build monitoring and actionable alerts
Monitoring collects evidence about service behavior. Alerting interrupts a person. SREs define both, but an alert should fire because a human needs to take a timely action, not simply because a metric changed.
User-impact symptoms are usually better paging signals than isolated internal causes. A rising failed-request ratio may justify a page; elevated CPU may be supporting evidence or an early capacity signal. Cause-based alerts remain useful when a specific condition reliably predicts impact and has a known response.
Every page should identify the affected service and environment, current impact, owner, evidence window, runbook, and escalation path. Missing telemetry must also have deliberate behavior: silently treating an unavailable query as healthy can hide both the original incident and a broken monitoring path. The alerting best-practices guide explains ratios, low-traffic safeguards, stable routing labels, grouping, and end-to-end tests.
Respond to incidents and learn from them
During an incident, the first priority is limiting user harm. Clear roles separate operational command, investigation, and communication so responders do not duplicate work or make conflicting changes. The incident record should preserve timestamps, observations, decisions, mitigations, owners, and recovery verification.
Recovery and resolution are not always the same moment. A rollback may restore service before the team understands the contributing conditions or completes a permanent correction. Tracking these boundaries prevents a fast mitigation from hiding unfinished reliability work.
After a significant incident, a blameless postmortem examines how the system, safeguards, assumptions, and organizational conditions allowed the outcome. “Blameless” does not mean avoiding accountability. It means replacing personal blame with owned, dated actions that improve the service. Google's postmortem guidance describes postmortems as a way to document contributing causes and drive preventative work.
Make change safer
Changes are necessary; SRE does not exist to stop them. SREs improve delivery safety with reproducible builds, automated validation, progressive exposure, canary analysis, feature controls, deployment markers, and tested recovery paths. A release should expose enough identity—such as service, environment, and version—to connect a regression to the change that introduced it.
Mitigation must still respect authorization and data safety. A runbook that says “restart everything” or “roll back” without prerequisites, scope, validation, and ownership can turn one failure into a larger incident. Safe automation has bounded inputs, observable results, a failure path, and a clear operator.
Plan capacity, performance, and dependency behavior
Capacity work translates expected demand into resource and dependency requirements. It includes load testing, saturation behavior, quotas, queue limits, retry budgets, timeouts, and overload controls—not just adding more instances.
SREs also examine how a service fails. Unbounded retries can amplify a dependency outage; an unbounded queue can exchange visible rejection for memory exhaustion and stale work. A reliable service defines what it accepts, delays, sheds, retries, or drops, and makes those outcomes observable.
Reduce toil with engineering
Google defines toil as production-service work that tends to be manual, repetitive, automatable, tactical, without enduring value, and proportional to service growth. Examples can include repeatedly applying the same recovery, manually provisioning similar resources, or processing routine operational tickets.
Not all operational work is toil. The first investigation of a new failure can create lasting knowledge. Updating a weak runbook or fixing a noisy alert can have enduring value. Even running a script may remain toil if a person must repeatedly notice the condition, choose the inputs, execute it, and verify it.
Google caps aggregate operational work for its SRE teams at 50% so engineers retain time for development. That is Google's organizational model, not a universal industry target. Other teams should measure where time goes, identify work that scales with service demand, and reserve enough engineering capacity to remove its causes. The important outcome is that growth does not require a matching increase in manual interventions. Google's toil guidance recommends measuring toil in consistent units and addressing root causes incrementally.
SRE vs DevOps, platform engineering, and operations
These disciplines overlap, but each answers a different question. Treating them as competing labels creates unnecessary organizational boundaries.
SRE and DevOps are complementary
DevOps emphasizes collaboration, shared ownership, automation, fast feedback, and reducing the divide between development and operations. SRE provides a concrete reliability operating model through SLIs, SLOs, error budgets, toil control, on-call practices, and incident learning.
Google's SRE introduction says SRE can be viewed as a specific implementation of DevOps. A team can use DevOps delivery practices without a formal SRE model, and an SRE team should still share responsibility with developers. SRE should not become a gate that receives unreliable software after developers finish their work.
SRE and platform engineering solve different primary problems
Platform engineering creates reusable internal capabilities—often an internal developer platform, self-service workflows, templates, and supported paths—that reduce developer cognitive load. Google Cloud's platform-engineering overview describes these “golden paths” as products for internal developers.
SRE focuses on reliability outcomes and the operation of services. The overlap is valuable: a platform can encode safe deployment, telemetry, ownership, and recovery standards, while SRE evidence can show where the platform needs improvement. A platform team may own shared infrastructure; it does not automatically own every product's SLO or incident response.
SRE changes traditional operations rather than dismissing it
Systems, networking, databases, security, and production experience remain essential. SRE changes how recurring operational demand is handled: teams use software, measurement, and feedback to prevent manual work from scaling with the service.
An SRE team must not become a general ticket queue or a destination for every task developers do not want. If product teams hand over all reliability responsibility, the incentives that SRE is meant to align separate again. Developers should remain involved in production readiness, on-call learning, incident reviews, and reliability fixes.
How a small team can start using SRE
A small organization can adopt SRE one service at a time. It does not need to rename a role, buy a broad platform, or copy Google's team structure.
1. Assign one service and one owner
Choose a service with meaningful user impact and a team able to change it. Document the service boundary, technical owner, product owner, dependencies, environments, and escalation path. Avoid beginning with “the whole platform,” where ownership and measurements become vague.
2. Map one critical user journey
Describe what a user tries to accomplish and where it enters and leaves the service. For a checkout flow, this may include starting checkout, validating the cart, authorizing payment, and receiving confirmation. Select a boundary the team can observe consistently.
3. Define an SLI from eligible events
Write the numerator and denominator in plain language before choosing a tool or query. Specify exclusions such as synthetic checks, explicitly canceled work, or invalid requests only when product and engineering agree they are outside the promise. Keep both counts at the same boundary.
4. Set an initial SLO and error-budget policy
Use current evidence and user expectations to choose a defensible target, then document the compliance period and calculation. State who reviews the result and what changes when the service consumes or exhausts its budget. The first objective can be revised as measurement improves; hiding uncertainty behind an arbitrary number cannot.
5. Build alerts and a usable runbook
Page on conditions that threaten the user journey or consume budget fast enough to require action. The runbook should establish impact, name safe first checks, link to bounded evidence, define escalation, and explain recovery verification. Test the rule, notification route, access, and handoff rather than trusting configuration alone.
6. Measure on-call load and repeated work
Record pages, manual recoveries, tickets, interruptions, and time spent on recurring tasks. Group them by cause and service impact. Automate or eliminate a high-value repeated task, then verify that the operational demand actually falls.
7. Review incidents and close actions
For significant failures, reconstruct the timeline and contributing conditions. Create a small number of specific actions with owners, due dates, and verification criteria. Track whether actions are completed and whether they prevent or limit recurrence; a long postmortem without follow-through is only documentation.
8. Review the model when evidence changes
Revisit the SLI when known user-impacting incidents do not consume budget, or when budget loss has no meaningful user effect. Review alert performance, runbook accuracy, dependency assumptions, capacity, on-call sustainability, and unfinished incident actions after relevant changes and incidents. A fixed ceremonial cadence is less useful than a review triggered by evidence.
How logs support SRE work
SRE needs several kinds of evidence. Metrics can quantify service behavior and drive SLO calculations. Traces can connect work across instrumented components. Deployment records identify changes. Incident systems coordinate response. Logs preserve detailed events that help explain what happened.
A useful application event might include an event timestamp, severity, event name, service, environment, version, instance or workload identity, and a safe request or interaction ID. Sensitive values such as tokens, passwords, session IDs, request bodies, and unnecessary personal data should be excluded or redacted before collection. The log-management best-practices guide covers schema, retention, access, pipeline testing, and AI safeguards.
Logs should not become an improvised SLO system unless event delivery, duplication, sampling, field types, and query definitions are controlled and validated. A missing upstream event cannot be recovered by the storage destination. During an incident, compare logs with the separately sourced service indicators, traces, deployment history, and dependency status before accepting a causal claim.
Fluxtail is a paid, logs-focused service with self-service Starter and Pro plans. After a supported collector sends records through a configured receiver, it provides named streams, search and filters, Live Tail, and alerts over retained events. Collector and receiver mappings determine which source attributes become searchable service, severity, label, or workload fields, so verify a known event before relying on those fields in a runbook or alert.
Fluxtail does not provide metrics, distributed tracing, APM, SLO computation, on-call scheduling, or incident management. It can serve as the searchable log evidence layer beside systems responsible for those functions. Its built-in AI chat and hosted MCP server are separate investigation interfaces. Hosted MCP uses OAuth with PKCE, binds access to one account, and applies the underlying account permissions. Raw events remain the evidence; stream or receiver changes are proposed first and require a short-lived confirmation before application.
When retained service logs are the missing part of the reliability workflow, review Fluxtail Live Tail and create a paid account to validate collection, field mappings, searches, and alert behavior with your own service.
Common SRE anti-patterns
SRE vocabulary does not create a reliability practice by itself. Watch for these failure modes:
- Treating 100% as the default objective. It usually prevents meaningful risk trade-offs and can drive disproportionate cost. Start from user need and measurable service behavior.
- Using infrastructure health as the only SLI. Healthy nodes do not prove that a user journey works. Measure at a boundary that reflects the service promise.
- Paging on every unusual signal. Pages should lead to timely action. Route non-urgent work to tickets or dashboards, and retain diagnostic events without interrupting someone.
- Turning SRE into a ticket queue. Repetitive work must create pressure for automation, simplification, or ownership changes rather than permanent manual staffing.
- Transferring reliability away from developers. The team that builds the service must participate in its production readiness, incident learning, and reliability improvements.
- Counting toil without reducing it. Measurement is useful only when it changes priorities and creates durable engineering work.
- Automating unsafe actions. Automation needs authorization, bounded scope, validation, observable failure behavior, and a clear owner.
- Writing postmortems without closing actions. Learning requires verified improvements, not just a completed document.
What SRE changes in practice
SRE makes reliability an explicit engineering and product concern. Teams define the user behavior they intend to protect, agree on how much risk is acceptable, and use that policy to guide changes. They prepare for incidents, learn from failures, and invest in systems that reduce repeated human intervention.
The smallest useful adoption is not a new department. It is one owned service with a user-centered SLI, a defensible SLO, an agreed error-budget policy, actionable alerts, a tested runbook, and time reserved to improve what on-call work reveals. That is enough to begin practicing Site Reliability Engineering—and enough evidence to decide what the organization should build next.