You build it, you run it (why developers should also be on call)
summary
Argues that putting developers on call closes the missing production feedback loop so teams see real user metrics, fix performance and app-layer bugs faster, and choose tooling with support costs in mind. Recommends aggregated logging (ELK, Logentries, Papertrail), real‑time metrics and dashboards (Graphite/statsd style), PagerDuty/OpsGenie for routing, and safety patterns like feature flags, graceful degradation, bulkheads and redeploying a known good build. Uses metrics-driven development and prescribes an on‑call ABC: assess, blast radius, compensate. Suggests one‑week rotas, teams of ~6–8, blameless postmortems (examples: GitLab DB, AWS S3).
AI-written summary · about
chapters (9)
- 0:00Start
- 7:31Metrics Driven Development The use of real-time metrics to drive rapid precise, and granular software iterations
- 8:56Developers On-Call is an evolution of Metrics Driven Development
- 13:53Operating in Production is an oft neglected use-case of a Product
- 14:36Ownership Being on call for your own product is more about risk management than control
- 22:18Ownership of runtime success belongs to the team
- 31:36Agree a reasonable SLA for alert acknowledgement • Have escalation policies to provide support when needed
- 34:36Be mindful of the cognitive weight of on-call
- 38:23Devs on call is fast becoming an industry standard
related talks
44mYou build it, you run it
27mYou Should Be On Call, too
22mRaise a Production System:Making on-call human-scale w/ Observability & Trust
31mHow to Build a Healthy On-call Culture
29mCalling out a terrible on call system
26mBuild a data-driven on-call workflow for your team with atomic habits
35mThriving With Kubernetes On-Call: Best Practices & Lessons Learned
24mWait for Us! Evolving On-Call as Your Company Grows