stabilitylisted

# /stability -- Achieve Stability **Pillar 3 of The Five Pillars.** Audits production readiness and incident-response process. ## When to invoke - Before a major release or migration - After a production incident, as part of the retrospective - Evaluating whether a team is ready to increase deployment frequency ## What it checks 1. **Breaking point** -- does the team know its system's actual capacity limits (load, data volume, dependency limits), or is this unknown until an incident finds it? 2. **Incident history** -- frequency, severity, and whether each incident got a complete, executive-visible investigation (not just a quiet fix) 3. **Recovery process** -- how fast can the team detect and recover from an incident today? Is there a runbook, or is recovery ad hoc? 4. **Deploy-while-stable track record** -- can the team ship new releases without a corresponding spike in incidents? ## Inputs - **Incident history** -- an incident tracker export (PagerDuty, Statuspage, Opsgenie), a pasted incident log/postmortem doc, or the repo's `incidents/`/`postmortems/` folder if one exists - **Breaking point** -- load test results, monitoring dashboards (APM, CloudWatch, etc.), or -- if none exist -- the honest answer "unknown, never tested" is itself the finding - **Recovery process** -- a runbook doc if one exists; otherwise ask how the last incident was actually resolved and treat the answer as the current (informal) process - Never fabricate incident counts or MTTR numbers to