Site Reliability Engineer career ladder: levels, titles, and criteria

Q: What is the difference between an SRE and a DevOps engineer?

This is the single most common point of confusion between the two roles, and the honest answer is that the boundary is blurry in practice. The cleanest distinction: SREs are accountable for reliability outcomes in production, measured through SLOs and error budgets, and they carry on-call for those outcomes. DevOps engineers are accountable for the delivery pipeline, getting code shipped quickly and safely through CI/CD and infrastructure automation. An SRE asks "is the error budget for checkout still healthy this week?" A DevOps engineer asks "can we cut deploy time from 20 minutes to 5?" Many companies, especially smaller ones, combine both into a single role or team; larger companies with dedicated SRE orgs (the model Google popularized) tend to keep them separate, with DevOps-style platform teams building the pipelines SREs then hold accountable to a reliability bar.

Q: What does an error budget actually mean in practice?

If a service has a 99.9% availability SLO, its error budget is the remaining 0.1%: the amount of downtime or failed requests allowed in a given period before that budget is spent. While budget remains, teams can ship features and take normal risk. Once the budget is exhausted, the SRE practice typically requires a freeze on new feature launches until reliability work brings the service back within budget. This is the mechanism that turns "reliability" from a vague goal into an enforceable, data-driven policy.

Q: Do SREs need to write code?

Yes. Most SRE teams require software engineering skill comparable to a backend engineer's, because the job includes building automation, writing tooling for chaos testing and failure injection, and sometimes contributing directly to the services they support. The stereotype of SRE as a purely operational, non-coding role is outdated at companies running a real SRE practice.

Q: How is this different from the general software engineer career ladder?

The general engineering ladder describes seniority progression that applies across specializations. This page is specific to reliability work: SLOs, incident response, capacity planning, and resilience architecture, rather than feature delivery. The scope of judgment expected at each level tracks the general ladder, but the concrete responsibilities and promotion evidence are reliability-specific.

Career levels, titles, scope, and promotion criteria for site reliability engineer roles — from entry level to senior leadership.

Last updated August 2026

site reliability engineer career ladder — quick overview

A site reliability engineer career ladder typically runs five levels: Associate SRE -> SRE II -> Senior SRE -> Staff SRE -> Principal SRE. The shift from Senior to Staff is where scope moves from owning reliability for one domain of services to designing resilience patterns and setting observability standards across many systems.

Turn this ladder into a live framework for your team. Start free →

Site Reliability Engineer IC career levels

Level	Title	Scope	Key differentiator	Typical YoE
IC1	Associate SRE	Supports the on-call rotation with senior backup	Responds to alerts with a senior engineer as backup; writes and updates runbooks; learns the monitoring and observability stack (metrics, logs, traces)	0-2
IC2	SRE II	Owns reliability for a service	Defines SLIs and SLOs for owned services; carries on-call as a full rotation member; writes blameless postmortems after incidents they were involved in	2-4
IC3	Senior SRE	Owns reliability for a domain of systems	Leads incident response as incident commander; enforces error-budget policy (when a team should stop shipping features and fix reliability); does capacity planning for their systems; mentors newer on-call engineers	4-7
IC4	Staff SRE	Cross-system reliability architecture	Designs resilience patterns (failover, graceful degradation, chaos testing) that span multiple systems; drives major incident postmortems to completed remediation; sets observability standards other teams adopt	7-10
IC5	Principal SRE	Company-wide reliability strategy	Owns the SLO framework and error-budget policy company-wide; sets incident-response process and severity definitions; represents reliability concerns in company architecture reviews	10+

Note: This ladder covers reliability-specific scope (SLOs, on-call, incident response, capacity planning). For the general engineering IC ladder and management track that applies across specializations, see the main engineering career ladder page.

How the Site Reliability Engineer career path progresses

A site reliability engineer career path is measured by how much of the reliability story one person is accountable for. Early on, an SRE responds to alerts with a senior engineer as backup. By Staff, the engineer is designing the resilience patterns, like failover and graceful degradation, that keep systems up in ways individual on-call responses cannot. The Senior-to-Staff jump moves an SRE from owning reliability for a domain of systems to setting the observability and resilience standards other teams adopt.

1

Respond with backup

As an Associate SRE, the work is responding to alerts with a senior engineer as backup, writing and updating runbooks, and learning the observability stack. Promotion evidence is handling an incident correctly without needing the senior engineer to take over.
2

Own reliability for a service

As an SRE II, ownership becomes a service's reliability end to end: defining SLIs and SLOs, carrying a full on-call rotation, and writing blameless postmortems for incidents they were part of.
3

Lead incident response for a domain

As a Senior SRE, scope widens to a domain of systems, and the role includes leading incident response as incident commander, enforcing error-budget policy, doing capacity planning, and mentoring newer on-call engineers. This is where an SRE starts making the call to stop feature shipping for reliability work.
4

Design cross-system resilience

As a Staff SRE, the work becomes designing resilience patterns like failover and chaos testing that span multiple systems, driving major postmortems all the way to completed remediation, and setting observability standards other teams adopt without being told to.
5

Set reliability strategy company-wide

As a Principal SRE, scope is the company-wide SLO framework and error-budget policy, setting incident-response process and severity definitions, and representing reliability in company architecture reviews.

Note: This ladder is IC-only. SRE and DevOps overlap heavily and some companies merge the roles, but this ladder is built around reliability outcomes, measured through SLOs and on-call ownership, rather than delivery-pipeline speed. See the FAQ for the fuller distinction, including what an error budget means in practice.

Skills and competencies by level

Each level below lists the hard skills (tools, techniques, deliverables) and soft skills (judgment, communication, stakeholder handling) that typically distinguish it.

Early (Associate SRE / SRE II)

Hard skills

Alert response. Follows a runbook to resolve a paging alert correctly under time pressure.
SLI/SLO definition. Defines a service-level indicator that actually reflects user-facing pain, not just an easy-to-measure metric.
Observability stack fluency. Uses metrics, logs, and traces together to find the actual cause of an issue, not just the symptom.
Runbook authoring. Writes a runbook precise enough that the next on-call engineer can follow it without asking questions.

Soft skills

Calm alert triage. Stays methodical when three alerts fire at once instead of chasing the loudest one first.
Blameless postmortem writing. Documents what happened without assigning fault, focused on what the system should have caught.
Backup escalation clarity. Knows exactly when to hand an incident to the senior engineer on backup rather than pushing through alone.
On-call handoff discipline. Leaves the next on-call engineer a clear picture of what is still unresolved.

Senior (Senior SRE)

Hard skills

Incident command. Runs a live incident as commander, coordinating multiple responders without losing track of the timeline.
Error-budget enforcement. Applies error-budget policy to stop feature shipping when a service is over budget, and makes it stick.
Capacity planning. Forecasts when a system will hit a scaling limit before it actually does.
Postmortem-to-remediation tracking. Keeps a postmortem action item alive until it actually ships, not just until the doc is filed.

Soft skills

Cross-team reliability negotiation. Gets a product team to accept a feature freeze because the error budget is spent, without it becoming adversarial.
Incident commander composure. Keeps a room of responders focused and calm during a major outage.
On-call mentoring. Coaches a newer on-call engineer through their first major incident without taking over.
Severity judgment. Calls the right severity level for an incident quickly, avoiding both under- and over-escalation.

Staff (Staff SRE)

Hard skills

Resilience pattern design. Designs failover and graceful-degradation behavior that holds up when a dependency actually fails.
Chaos testing programs. Runs controlled failure injection that surfaces real weaknesses without causing a real outage.
Cross-system observability standards. Sets the logging and tracing conventions that make an incident spanning several systems traceable at all.
Major postmortem remediation. Drives a company-impacting postmortem's fixes to completion across teams that do not report to them.

Soft skills

Standard adoption across teams. Gets multiple teams to adopt a shared observability convention because it makes their own incidents easier to debug.
Cross-org incident coordination. Coordinates a response spanning systems owned by several different teams during a major outage.
Reliability investment advocacy. Makes the case for resilience work against a roadmap of feature asks, backed by real incident cost.
Postmortem facilitation at scale. Runs a postmortem review that surfaces the real systemic issue instead of a surface-level explanation.

Principal (Principal SRE)

Hard skills

SLO framework ownership. Owns the company-wide model for how services define and are held to SLOs.
Severity and process definition. Sets the incident severity levels and response process every team follows during an outage.
Error-budget policy design. Designs the error-budget policy that balances reliability against feature velocity at company scale.
Architecture risk review. Reviews a new system design for reliability risk before it ships, not after the first incident.

Soft skills

Company-wide reliability representation. Represents reliability concerns in an architecture review alongside product and platform leadership.
Executive incident communication. Briefs leadership on a major incident's impact and fix plan in terms they can act on.
Cross-org policy enforcement. Gets competing engineering orgs to actually honor a shared error-budget policy, not just agree to it in a meeting.
Reliability culture building. Makes blameless postmortems and error-budget discipline a norm teams follow without being watched.

Common questions

Frequently asked questions

What is the difference between an SRE and a DevOps engineer?

What does an error budget actually mean in practice?

Do SREs need to write code?

How is this different from the general software engineer career ladder?

Build your Site Reliability Engineer career framework in Harmny

Turn this career ladder into a live system — employees see their gap to the next level, and development goals connect directly to the framework.

Start free See competency frameworks →

Related career ladders

Backend Engineer career ladder Data Engineer career ladder DevOps Engineer career ladder Frontend Engineer career ladder Machine Learning Engineer career ladder Mobile Engineer career ladder

All career ladders → Career progression framework guide Competency matrix template Career pathing software