Site Reliability Engineering (SRE) is the approach born at Google in 2003 to reconcile two goals that seem to conflict: shipping fast and staying stable. This page is for developers, Ops and technical leads who are discovering SRE and want to understand its principles before applying them. It covers the origin of the movement, its five fundamental principles (reliability as a feature, rejecting 100 %, error budget, toil, the 50 % rule), the difference with DevOps, and where SRE stands in 2026 in the face of AI-driven automation.
What you will learn
- Understand why Google created SRE and which problem it solves
- Distinguish SRE and DevOps without opposing them
- Identify toil in your own organisation and why it must be eliminated
- Arbitrate between velocity and stability with the error budget
- Place the concrete responsibilities of an SRE team
Where does Site Reliability Engineering (SRE) come from?
The problem: Dev vs Ops
Traditionally, companies strictly separated two teams:
- Developers (Dev): write code, want to ship features quickly
- Operations (Ops): keep production systems running, want to avoid changes that could cause outages
These two goals are fundamentally in tension. Most incidents are caused by changes: a new feature, a configuration update, a bug fix. From the Ops point of view, fewer changes means fewer incidents. From the Dev point of view, fewer changes means a stagnating product and unhappy users.
This tension creates a vicious circle. Ops set up ever heavier approval processes. Dev work around them (small "hotfixes" that fly under the radar). Trust erodes. Both teams end up in opposite trenches, each convinced the other is the source of the problem.
Google's answer: ask software engineers to run operations
In 2003, Benjamin Treynor Sloss, then VP Engineering at Google, had a simple but radical idea: what if software engineers designed operations?
Instead of hiring traditional system administrators, Google recruited developers with a taste for systems. These engineers, by nature, hate repetitive work. Their reflex: automate everything that can be automated rather than redo it by hand every week.
This approach gave birth to Site Reliability Engineering. The name says it all: it applies the principles of software engineering (design, automation, measurement) to the problem of site reliability (production systems). More than twenty years later, this philosophy remains the most cited reference among platform and infrastructure teams that structure their reliability practice.
The fundamental principles of SRE
SRE rests on several interconnected principles. Understanding these principles means understanding why SRE works where the traditional approach fails.
Principle 1: reliability is a product feature
In a traditional team, reliability is the exclusive responsibility of Ops. Dev ship code, Ops make sure it runs. If it goes down, it is "an infrastructure problem".
SRE reverses this view. Reliability is a product feature, just like new features. A service that crashes constantly brings no value, whatever the number of features it offers.
This responsibility is shared between Dev and SRE teams. Developers can no longer throw their code over the wall and expect Ops to cope.
Principle 2: 100% availability is not a goal
This is perhaps the most counter-intuitive SRE principle. You might think the goal is to reach 100 % availability. In reality, aiming for that level is counterproductive.
Why? Three reasons:
-
It is technically impossible. There will always be hardware failures, human errors, natural disasters.
-
The gain becomes imperceptible. Beyond a certain level, the weakest link is no longer your service: the user's WiFi network, mobile carrier and browser introduce greater instability. This level depends on the service and the user journey: an internal messaging tool and a payment platform do not place it at the same point. The useful question is therefore not "how many nines", but what your users perceive of your reliability.
-
The marginal cost explodes. Each extra nine costs much more than the previous one: redundancy, automatic failover, reinforced on-call, failure testing. The progression is geometric, but its factor depends on your architecture and no SRE law sets it. Once you reach the level your users need, these resources produce more value elsewhere.
SRE offers an alternative: define a realistic reliability objective (the SLO) and use the tolerated error margin (the error budget) as a decision tool.
Principle 3: the error budget resolves the Dev/Ops conflict
The error budget turns a destructive tension into an objective decision mechanism.
Imagine a service with a 99.9 % SLO of monthly availability. This means you tolerate 0.1 % unavailability, about 43 minutes per month. That is the error budget.
As long as there is budget left:
- Developers can deploy features
- You can take calculated risks
- Innovation is encouraged
When the budget is exhausted:
- You stop non-critical deployments
- You focus on stability
- You invest in automation and tests
The conflict disappears because the decision is no longer political but data-driven. Developers themselves become careful when the budget shrinks: they do not want to waste it and block their own releases.
Principle 4: toil is the enemy
Toil is a central SRE concept. It refers to operational work that has these characteristics:
| Characteristic | Explanation | Example |
|---|---|---|
| Manual | Requires human intervention | Restarting a crashing service |
| Repetitive | Happens again and again | Clearing logs every Monday |
| Automatable | A machine could do it | Provisioning a new server |
| Tactical | Reactive, not strategic | Answering an alert without fixing the cause |
| No lasting value | The system returns to the same state afterwards | Rerunning a failed job |
| Scales with load | Grows with the number of users | Handling support requests manually |
Toil is dangerous because it grows linearly with the size of the service. If you need 2 people to handle 1,000 users, you will need 20 people for 10,000 users. This model is not viable at scale.
According to the reference book Site Reliability Engineering, Google's quarterly internal surveys show an average toil time of about 33 %, below the 50 % threshold set as the target. But the average hides strong disparities: some SREs report 0 % toil (pure engineering projects), others up to 80 %. This contrast is what justifies measuring toil team by team rather than relying on an overall average.
Principle 5: the 50% rule
Google applies a strict rule: SREs must not spend more than 50 % of their time on operational work, that is toil, on-call and tickets.
The remaining 50 % must go to engineering projects:
- Automating manual tasks
- Improving monitoring tools
- Strengthening the system's resilience
- Developing self-healing features
This rule has two effects:
-
It forces automation. If toil exceeds 50 %, the team must either automate or send work back to the Dev teams.
-
It keeps the job attractive. SRE engineers are not "super sysadmins" condemned to routine. They do engineering.
How SRE works in practice
The velocity/stability balance
SRE does not try to maximise stability at the expense of velocity. It looks for the optimal balance for the business.
This balance depends on the context:
| Type of service | Priority | Typical SLO |
|---|---|---|
| Critical infrastructure (payments, authentication) | Stability | 99.99 %+ |
| Mature consumer product | Balance | 99.9 % |
| Product in its growth phase | Velocity | 99.5 % |
| Prototype / MVP | Innovation | 99 % |
A product in its growth phase can accept more incidents because iteration speed is crucial. A payment system cannot afford to go down: users lose trust immediately and the reputation suffers for a long time.
Monitoring: three kinds of output
SRE defines three kinds of possible responses for monitoring. This classification forces you to think about each metric before even implementing it: what human reaction do you actually expect if this condition occurs?
Definition: an alert requires immediate human action.
When to use it: the service is degraded now or will be within minutes. A human must step in.
Example: the error rate exceeds 5 % over the last 5 minutes.
Pitfall to avoid: too many alerts means alert fatigue, which means ignored alerts, which means missed incidents.
Definition: a ticket requires human action, but not immediately.
When to use it: there is a problem to handle in the coming days, but the service works correctly.
Example: the disk will reach its limit in 2 weeks at the current rate.
Pitfall to avoid: tickets that pile up without ever being handled.
Definition: information recorded for later analysis. Nobody looks at it in real time.
When to use it: data useful for post-incident diagnosis or trend analysis.
Example: the response time of each request.
Pitfall to avoid: logs that should have been alerts.
Incident management and learning
SRE treats incidents as learning opportunities, not as failures to punish.
Two principles guide this approach:
-
Humans make mistakes. It is inevitable. The system must be designed to withstand human errors.
-
The blameless postmortem. After an incident, you analyse what happened to improve the system, not to find someone to blame.
SRE in the face of agentic AI in 2026
The SRE landscape has been changing fast since the arrival of artificial intelligence agents able to observe telemetry, form hypotheses about a root cause and propose or execute a remediation. This section takes stock of what actually changes, without giving in to the industry's exaggerated marketing promises.
The 2026 edition of the annual Catchpoint report on SRE practices, based on a survey run in July and August 2025 among 418 practitioners, measures a median toil of about 34 % of working time, unchanged from previous editions despite the massive adoption of AI. The effect of AI is mixed and splits into three groups: 49 % of respondents see their workload decrease, 35 % no change, and 16 % an increased workload. The reason is simple: part of the manual work disappears, but new work appears in its place (supervising the quality of an agent's decisions, maintaining the models, running the underlying infrastructure).
The current capabilities of agents remain limited in real scenarios. The ITBench benchmark, published by IBM Research and presented at ICML 2025, gathers 94 scenarios, including 42 for SRE, drawn from incidents observed on IBM's SaaS products. Agents built on the best models solve only about one SRE scenario in eight (13.8 % in the version published on arXiv in February 2025, 11.4 % in the one presented at ICML) and a quarter of the compliance scenarios: full automation remains far from replacing human on-call. The open MCP protocol (Model Context Protocol) is gradually becoming the standard connection between these agents and observability tools, which avoids being locked into a single vendor's ecosystem.
What this means concretely for a team starting with SRE today: AI agents are an investigation accelerator (log correlation, incident summary, probable cause suggestion) rather than a substitute for human decision on risky actions. The fundamental principles (error budget, eliminating toil, blameless postmortem) remain the foundation these tools build on: an agent that automates a badly defined process only speeds up the chaos.
SRE vs DevOps: what is the difference?
SRE and DevOps share many principles. SRE is often described as a specific implementation of DevOps principles, with a few extensions.
| Aspect | DevOps | SRE |
|---|---|---|
| Origin | Community movement (2009) | Google practice (2003) |
| Focus | Culture and collaboration | Engineering and measurement |
| Prescriptive | General principles | Concrete practices (SLO, error budget, 50 % rule) |
| Teams | Dev/Ops merger | Distinct but collaborative SRE team |
| Measurement | DORA metrics | SLI/SLO/error budget |
You can see DevOps as the philosophy and SRE as a methodology to apply it. The DORA metrics framework has itself evolved: it now has five software delivery performance metrics, no longer the original four. Three measure throughput (deployment frequency, change lead time, failed deployment recovery time) and two instability (change fail rate, deployment rework rate). Reliability is not among them: it belongs to SLOs. The two frameworks therefore complement each other, and each keeps its own purpose.
The responsibilities of an SRE team
A typical SRE team is responsible for several complementary areas, which overlap with those of a platform team in the sense of Team Topologies: guaranteeing a service that is usable every day, while freeing engineering time to evolve it without breaking users' trust.
-
Availability: making sure the service is reachable when users need it
-
Latency: guaranteeing acceptable response times for a good user experience
-
Performance: optimising resource usage for a controlled cost
-
Change management: deploying new versions without breaking the service
-
Monitoring: detecting problems before they affect users
-
Incident response: restoring the service quickly when it goes down
-
Capacity planning: anticipating growth to avoid saturation
Can you do SRE without being Google?
SRE was born at Google, a company with exceptional resources and scale. But its principles apply to any organisation, including a team of a few developers running a single service in production.
What adapts easily
Some SRE principles need neither budget nor a dedicated team: they rely on a measurement discipline and a culture, two things a small team can adopt tomorrow.
- Error budgets: work as soon as you have SLOs, even informal ones
- Eliminating toil: relevant to any team doing repetitive work
- Blameless postmortems: culture, not infrastructure
- Monitoring in 3 categories: applicable immediately
What needs context
Other aspects of SRE as practised at Google assume an organisation size or a relationship maturity that not all teams have yet. Recognising them avoids aiming for an illusory compliance.
- Dedicated SRE team: requires a certain organisation size
- 50 % rule: hard if the team is already drowning in toil
- Shifting load to Dev: assumes a good relationship with the Dev teams
What matters is adopting the principles of SRE, not necessarily its exact structure. A small team can perfectly apply the SRE philosophy without a dedicated "SRE" role, relying for example on the practices described in the Platform Engineering guide (in French).
Key points
-
SRE reconciles Dev and Ops by turning the velocity/stability conflict into a data-driven decision (the error budget)
-
100 % availability is not the goal: you aim for a reliability level suited to the business and use the error margin to innovate
-
Toil is the enemy: every repetitive manual task must be automated or eliminated
-
SREs do engineering, and at Google at least 50 % of the time goes to projects that improve the system: a benchmark to adapt to your context, not a norm to impose
-
Incidents are learning opportunities, not occasions to blame
-
SRE is an implementation of DevOps: same principles, more prescriptive practices
-
In 2026, agentic AI remains an investigation accelerator, not a substitute for SRE principles or for human decision on risky actions
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: SRE in practice: reliability at scale
A new full quiz with random questions
Work again only on the questions you missed
Reference resources
Both Google books are free online and remain the primary source of the principles presented here: the first sets the doctrine, the second puts it into practice with examples outside Google. The Catchpoint report provides field figures on toil and the effect of AI.
- Site Reliability Engineering (Google book), the founding book, available free online
- The Site Reliability Workbook, the complementary practical guide
- SRE at Google (sre.google), the official site with resources and case studies
- The SRE Report 2026 (Catchpoint), annual survey of 418 practitioners on toil, on-call and the impact of AI
FAQ: frequently asked questions
The questions below cover the most frequent doubts about SRE: its difference with DevOps, the error budget and the place of toil in a small team.