ClearMeasureLabs /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
- 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?
- Incident history -- frequency, severity, and whether each incident got a complete, executive-visible investigation (not just a quiet fix)
- Recovery process -- how fast can the team detect and recover from an incident today? Is there a runbook, or is recovery ad hoc?
- 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 fill a gap in the data -- report "no incident tracking in place" instead
Example output
Stability audit -- Atlas API
Breaking point: Unknown -- no load testing on record. Team estimates ~500 req/s based on a prod incident 3 months ago, not a deliberate test.
Incident history: 4 incidents in 90 days, all Sev-2. Only 1 got a written postmortem; the other 3 were fixed and closed with no review.
Recovery process: No runbook. Last incident (DB connection pool exhaustion) was resolved by the one engineer who remembered a similar issue from a prior job.
Highest-risk gap: No postmortem discipline -- 3 of 4 incidents could recur with no institutional memory of the fix.
Recommended next step: Require a written postmortem (even a 1-paragraph one) for every Sev-2+ incident starting next week; write a runbook for the connection-pool issue specifically, since it's already recurred once.