On-call readiness checklist
A phase-by-phase checklist distilling the rest of this course into one pass: SLO and measurement readiness, on-call and incident readiness, reliability engineering readiness, and reporting and review readiness. This is a plain checklist — checking a box is a visual aid only, nothing is saved server-side or persisted across visits, so treat it as a working session for a team or service, not a tracked assessment.
☺ Explain it like I'm 10
A pilot's pre-flight checklist doesn't prove the plane will never have a problem in the air — it proves someone actually checked the known failure points before takeoff instead of assuming they were fine. This list works the same way for a service: it doesn't guarantee nothing breaks, it guarantees that when something does, the team isn't discovering for the first time that nobody agreed on severity levels or that a critical dependency has no timeout at all.
① SLO & Measurement readiness
An SLI is defined and instrumented for every critical user journey (checkout, login, the primary API) — not inferred from CPU or memory alone Each SLI measures from the request path itself (real user traffic or synthetic probes hitting the actual endpoint), not a proxy metric one layer removed from what the user experiences SLO targets are drafted and explicitly signed off by the product or business owner, not set unilaterally by engineering The SLO's measurement window (e.g. a 28-day rolling period) is written down alongside the target, not left implicit Error budget burn is on a dashboard the whole team can see, not a query only one engineer knows how to run A fast-burn alert (e.g. 2%+ of the budget consumed in one hour) is configured separately from the SLO threshold itself Error budget status is reported at least monthly to stakeholders outside the on-call rotation, not only reviewed internally ② On-Call & Incident readiness
A rotation is defined with a primary and secondary, plus an explicit acknowledgment window before a page escalates The escalation policy is configured and tested in the paging tool itself (PagerDuty, Opsgenie, or equivalent), not just described in a doc A written handoff checklist exists covering open incidents, services running degraded, unbaked recent deploys, and any alert currently flapping An incident severity matrix is documented with explicit criteria for who gets paged at each level, not decided ad hoc mid-incident The Incident Commander role is explicitly assigned during an incident and kept separate from whoever is actively debugging A Comms/Ops lead role is defined to own stakeholder and status-page updates, so subject-matter responders aren't interrupted mid-fix Every alert is symptom-based — it fires on user-facing impact, not a raw resource threshold that may or may not matter Every alert has been tested for actionability: it links to a runbook, and a recent audit confirms it isn't firing without a required response ③ Reliability Engineering readiness
A circuit breaker is configured on every critical outbound dependency call (database, downstream API), with a tuned failure threshold An explicit timeout is set on every network call in the critical path — none rely on a library or platform default Retry logic uses backoff with jitter and a hard cap, so a downstream blip can't turn into a retry storm that takes the dependency down further A progressive delivery pipeline is in place — canary or staged rollout with automated metric analysis gating promotion to full traffic The rollback path for the deploy pipeline has been tested end-to-end, not just documented as a theoretical option Bulkhead isolation (separate thread pools or connection pools per dependency) prevents one failing dependency from exhausting a shared resource pool At least one chaos engineering game day has been run against a critical dependency, with its findings tracked to closure ④ Reporting & Review readiness
A blameless postmortem template is in active use for every SEV1 and most SEV2 incidents Postmortem action items live in the team's normal backlog with an owner and a due date, not stranded in the postmortem doc itself A recurring reliability review is scheduled (biweekly or monthly) covering SLO status, error budget trend, and open action items An error budget policy is written down and tied to a concrete release decision — for example, feature launches pause when the budget is exhausted On-call load itself is reviewed on a cadence — pages per shift tracked as a health signal, not assumed fine by default Postmortems are reviewed in aggregate for repeat root causes and linked to a toil-reduction or automation backlog, not treated as one-off documents Reliability review output is shared with stakeholders outside the on-call rotation — leadership or product, not just the engineers who were paged