The record does not stop at detected.

One incident, end to end

1. Route it

   A routing policy decides which channels an event class reaches, and the scope it applies to is stored rather than inferred, so a deleted rule cannot quietly widen an audience. Maintenance windows suppress by reading timestamps, not by flipping state, and they are DST-safe.

2. Page a person

   On-call rotas and escalation ladders decide who is woken and when the next person is tried. Delivery is durable: attempts are append-only, retries walk from about a minute to six hours, and a lease is fenced so two workers cannot both own one message.

3. Run the runbook

   Bounded steps against the incident, from a typed action registry. Two of those actions involve a person, and when one runs the whole run suspends rather than pretending to continue.

4. Hand a step to a human

   The hand-over becomes a task with a deadline and an owner. The answer that comes back is stored beside the step that asked for it, and the run resumes when the task is completed or cancelled, or when the step it waits on reaches its own deadline.

5. Publish and close

   A status update posts from the incident screen to the public page, an objective's error budget is computed from the same observations the incident came from, and the postmortem is drafted from the real timeline instead of a blank page.

Who is woken

A page that was never delivered is not a page.

Escalation steps reach people by email, SMS or voice call. Email is always available; SMS and voice route through your own Twilio account, and steps on channels you have not configured are logged rather than silently skipped.

Every message has a ledger: queue pressure, attempts spent, when the next retry is due, and the reason it stopped. An attempt that never reported an outcome is visible as exactly that rather than counted as a success.

The delivery ledger

escalationrota, ladder, and what each step may use

Objectives