Capstone — the reliability checklist for a pipeline you can page on

At a glance

Learning objectives

• Run the reliability checklist over your own pipeline end to end
• Drill the incident path — match the alert, walk the runbook, capture the timeline
• Close with a blameless postmortem with dated, owned action items

What you need

• The pipeline you built across this series
• Its SLA, runbook and alert routing
• [object Object]

Steps

1. Declare the SLA — freshness and completeness — with the CI test that enforces it, because a contract with no enforcement is documentation. (from skill-data-contract-author )
2. Make every task idempotent so a re-run is always safe, and retry with backoff with a clear failure classification in the alert. (from runbook-pipeline-failed )
3. Keep a documented backfill runbook per pipeline. (from runbook-backfill-required )
4. When the alert fires, load the production playbooks into the agent, match the alert to a runbook, and walk the operator through diagnosis and mitigation step by step. (from plugin-runbook-runner )
5. The incident workflow — establish impact and start time; check for a correlated deploy; walk the matching runbook; capture the timeline for the postmortem. (from agent-incident-assistant )
6. The postmortem structure — impact in business terms with a duration; a timestamped, factual, no-blame timeline; how we found out, because if a human told us that's a gap; contributing factors, plural; action items each with an owner, a date and a "done" definition. (from skill-incident-postmortem-writer )
7. "Be more careful" is not an action item — change the system so a careful mistake is harmless. (from skill-incident-postmortem-writer )

Check yourself

• The checklist passes — SLA declared and enforced, tasks idempotent with backoff retries, backfill runbook documented, failure class in the alert text.
• A tabletop incident produces a rolling timeline and a draft postmortem with dated, owned action items.

Worked example

1. **Impact** — who/what, in business terms, with a duration.
2. **Timeline** — timestamped, factual, no blame.
3. **Detection** — how we found out; if a human told us, that's a gap.
4. **Contributing factors** — plural; incidents are rarely single-cause.
5. **Action items** — each with an owner and a date, and a "done" definition.

Establish impact and start time.
Check for a correlated deploy.
Walk the matching runbook.
Capture the timeline for the postmortem.

/runbook
/match-alert
/incident-timeline

Sourced from

• Data Contract Author
• Pipeline failed
• Backfill required
• Runbook Runner
• Incident Assistant
• Incident Postmortem Writer

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• "Be more careful" is not an action item — change the system so a careful mistake is harmless.
• If a human told you about the incident, detection is a gap.
• Incidents are rarely single-cause — contributing factors are plural.

Production considerations

• Capture the timeline as the incident happens, not from memory afterwards.
• The incident assistant suggests, never executes, production changes — it escalates to a human before any destructive step.

Diagram

reliability capstone
   |
   |- SLA declared + enforced --> freshness, completeness in CI
   |
   |- idempotent tasks + backoff retries --> reruns safe by construction
   |
   |- backfill runbook documented --> history fixable without fear
   |
   |- alert --> match runbook --> walk diagnosis --> capture timeline
   |
   |- postmortem --> impact, timeline, detection, factors, owned actions

Registry stats