On this page
What Is SRE (Site Reliability Engineering)?
Site reliability engineering applies software engineering to operations: SLOs, error budgets, and automation. Learn the core ideas and key practices.
Quick answer
- Site reliability engineering (SRE) treats operations as a software engineering problem.
- SRE teams define service-level objectives (SLOs) and use error budgets to decide when to slow down releases.
- A core goal is reducing “toil” — repetitive manual operational work — through automation.
What is SRE?
Site reliability engineering is a discipline, originating at Google, that applies software engineering practices to the operation of production systems. Instead of a separate team manually keeping servers alive, SREs write software and automation to do it, and they measure success with explicit reliability targets. The approach is documented in Google’s freely available “Site Reliability Engineering” books.
How does SRE work?
SRE is organized around a few core practices. An SLO (service-level objective) sets a measurable reliability target, like “99.9% of requests succeed in a month.” The error budget is the allowed failure — if the SLO is 99.9%, you can afford 0.1% errors — and it becomes a release throttle: burn the budget, and you stop shipping features until reliability recovers. SREs also measure and eliminate toil, the manual, repetitive work that scales with the number of tickets rather than the number of users.
Why does SRE matter?
SRE replaces vague promises of “high availability” with concrete numbers and a decision rule. It aligns product velocity and reliability by making the trade-off explicit, and it forces teams to automate the work that would otherwise consume engineers.
Where this bites vibecoders
A vibecoder’s “reliability plan” is usually absent: no SLO, no error budget, no on-call. The result is that reliability decisions are made by feel — ship whenever, fix when someone complains. Even solo builders benefit from one explicit target (“my API should succeed 99.5% of the time this month”) and one alert tied to it, because it turns “is this good enough?” into a number.
Where AI coding assistants get this wrong
- Generating dashboards with no SLOs, so “reliability” is never defined.
- Treating SRE as “the person who reboots servers” rather than an engineering discipline.
- Suggesting automation for toil without first measuring what the toil actually is.
- Confusing SLOs with SLAs and using contractual language internally.
Checklist
- Define one SLO for your service and measure it.
- Compute an error budget and use it to gate releases.
- Identify and reduce your top source of toil.
- Automate the response to predictable failures.
- Write runbooks for incidents before they happen.
FAQ
What is the difference between SRE and DevOps?
DevOps is a broad culture and set of practices; SRE is a specific implementation with concrete artifacts like SLOs and error budgets. SRE can be thought of as one rigorous way of “doing” DevOps.
What is toil?
Toil is manual, repetitive, automatable operational work that doesn’t create lasting value — restarting services, filing identical tickets, hand-running deploy steps. SRE aims to measure it and replace it with automation so engineers work on systems, not chores.
What is an error budget?
An error budget is the amount of failure a service is allowed before it misses its SLO. If your SLO is 99.9% availability, the remaining 0.1% is your error budget. When it’s spent, the team pauses feature work to fix reliability. See What Are SLA, SLO, and SLI?.