Site reliability engineering (SRE)
Also known as: SRE, site reliability engineer, reliability engineering
Site reliability engineering (SRE) is an approach to running production systems that treats operations as a software problem.
SRE teams set reliability targets, automate repetitive work, and use 'error budgets' to decide when to ship features and when to focus on stability. While many companies simply renamed their operations teams 'SRE,' the real practice changes how product and operations teams negotiate risk.
Site reliability engineering (SRE), explained at three levels
At home
Think of a building's maintenance team that, instead of fixing the same leaky tap every week, redesigns the plumbing so it stops leaking. Site reliability engineers do that for websites and apps. They keep systems running, but rather than repeating manual fixes, they write software to automate them, and they agree in advance how reliable a service needs to be so they know when to act.
At work
Site reliability engineering, or SRE, is an approach to running production systems that treats operations as a software engineering problem. SRE teams agree with the business on a reliability target for each service, automate repetitive work, and use the gap between the target and perfection to decide how fast to release. Businesses care because it balances new features against stability using data, not arguments.
At home
SRE uses three related terms. A service level indicator, or SLI, is a measurement, such as the share of page loads that succeed. A service level objective, or SLO, is the target for it, like 99.9% each month. The error budget is what's left over: 0.1% of requests may fail. While budget remains, the team ships features freely; once it's spent, effort shifts to fixing reliability.
At work
In practice, SRE teams define SLOs for user-facing journeys and alert when the error budget is burning too fast, rather than on every CPU spike. They cap toil, meaning manual and repetitive work, with Google suggesting under 50% of an engineer's time. Incidents are followed by blameless postmortems focused on causes, not culprits. Organizations run SRE as engineers embedded in product teams, a central team, or a consulting group that coaches others.
At home
Each extra nine of reliability costs far more than the last. At 99.9%, a service may be down about 43 minutes a month; at 99.99%, about 4. Getting there needs redundant systems, faster detection, and automated recovery, and users often can't tell the difference because their own Wi-Fi fails more often. In my view, SRE is valuable precisely because it forces that cost into the open.
At work
Mature SRE uses multi-window burn-rate alerts on SLOs, which page only when the error budget is being consumed fast enough to matter, cutting alert fatigue. Error budget policies, agreed with executives, define what happens when budgets run out, such as a release freeze; without that agreement, SLOs become decoration. Measure SRE by user-facing reliability, toil reduction, and incident trends, not ticket counts, and remember that your dependencies cap the SLO you can realistically promise.
Real-world examples
At home
Lena read the free Google SRE book while studying computer science. She applied its postmortem template to a group project failure, and the discussion focused on fixing the process rather than blaming whoever pushed the bad code.
At work
Marcus leads engineering at a Montreal payments startup. Product wanted weekly launches while outages were rising. He introduced SLOs and an error budget; when the budget ran out in March, the team paused features for two weeks and fixed the top three causes of incidents.
How it compares
| feature | Site reliability engineering (SRE) | DevOps |
|---|---|---|
| Main focus | Reliability targets and automation | Collaboration and delivery culture |
| Key tool | SLOs and error budgets | CI/CD and shared ownership |
| Origin | Google, 2003 | Community movement, around 2009 |
| Typical role | Dedicated SRE engineers | A practice across teams |
SRE is often described as one concrete way to implement DevOps ideas.
For analysts
Setting SLOs is really a business decision about how much downtime customers will tolerate. I'd involve product owners in choosing them, because an SLO picked only by engineers rarely matches what customers actually care about.
History & origin
Ben Treynor Sloss started Google's SRE team in 2003, famously describing it as what happens when a software engineer is asked to design an operations team. Google kept the practice largely internal until it published Site Reliability Engineering in 2016, followed by The Site Reliability Workbook in 2018. The books introduced service level objectives, error budgets, toil limits, and blameless postmortems to a wide audience. Job titles followed quickly, and by the early 2020s SRE was one of the most common infrastructure roles. In my opinion, SRE's most valuable idea isn't technical at all: it's that 100% reliability is the wrong goal.