Observability and reliability
Ownership models for on-call
Developer-owned on-call, dedicated SRE and hybrids each suit different systems. The failed middle is when SRE takes the pages for product bugs that product teams could fix.
Someone has to answer the page, and the question of who that is shapes everything else. There are three common models. Developer-owned on-call means the team that builds a service also runs it. Dedicated SRE or platform on-call means specialists run the systems. A hybrid splits the work, so platform specialists own shared infrastructure and product teams own their service pages.
The big idea
Think of a restaurant. In one kitchen, each cook is responsible for their own station, and a bad dish comes back to the cook who made it. In another, a separate team cleans up after everyone. The first gets fast feedback. The second gets deep specialist skill. The worst setup is when the cleaning team also has to fix the cooks' recipes.
Walking through it
| Model | Strength | Weakness |
|---|---|---|
| Developer-owned | Fast feedback, real ownership, fewer throw-it-over-the-wall bugs | Burns out product engineers unless the platform and rotations are humane |
| Dedicated SRE or platform | Deep operational skill and a consistent process | Turns into a ticket sink when product teams do not share the work |
| Hybrid | SRE owns shared platforms, and product teams own their service pages | Needs clear boundaries and a shared SLO language |
Trade-off
Prefer developer-owned on-call for the services a team ships, once paging is sane and a platform team provides paved roads for deploys, metrics, secrets and dashboards. Prefer dedicated SRE when the blast radius is company-wide infrastructure, or when regulation needs a specialized practice.
The failed middle deserves a name. It is when SRE takes every page for product bugs that the product team could fix. That trains nobody, and it overloads the specialists. The people who change the code should feel its pages. That keeps reliability work competing fairly with features, rather than being someone else's night problem.
Platform engineering exists partly to make developer on-call survivable, because golden paths beat tribal knowledge.
Common anti-patterns
- Hero rotation. The same two seniors take every hard week. The knowledge never spreads, and those two eventually quit.
- Silent secondary. The backup is never paged or practiced, and then fails when the primary is unreachable.
- Page-as-ticket. Overnight noise for work that should wait until morning. People learn to ignore the pager, including on the night something is actually on fire.
- No error-budget link. Product ships risk, while on-call absorbs the pages with no authority to slow releases. Tie paging pain to SLO policy, so the organization chooses on purpose.
- Runbook theater. Beautiful docs that nobody opens, because the alerts do not link to the right section.
Check yourself
- A product team's bugs keep paging the SRE team. Which model has failed, and what is the fix? The failed middle. Move those pages to the product team that owns the code, with the platform's support.
- Why do the people who change the code need to feel the pages? It makes reliability work compete fairly with features, and it gives the owners the best feedback.
Key takeaways
- Developer-owned, dedicated SRE and hybrid each fit different systems.
- Prefer developer-owned for services once paved roads and humane rotations exist.
- Avoid the failed middle, where specialists take product bugs they cannot fix.
Further learning
The career side of owning production is in production ownership. The platform side is in platform engineering.
Google's SRE Workbook and the Spotify talk both cover team models in practice.
Being On-Call (Google SRE book)Proven strategies for on-call engineers to ensure reliable services and maintain sustainable workloads in IT operations.sre.googleRelated
Designing on-call
Sustainable rotations, executable runbooks, toil budgets and a paging policy that keeps humans healthy while production stays covered.
Platform engineering
Internal developer platforms, golden paths and treating infrastructure as a product. Cut cognitive load without building a second Kubernetes.
Owning your code in production
On-call, alerts, runbooks, and the loop that makes you trustworthy — and better at building systems that survive users.