Read a postmortem, extract what generalizes.
The pattern that lets you learn from other teams' incidents without reading 40 pages of narrative every time.
Someone posted a postmortem — internal, or public (Cloudflare, GitHub, AWS). It's long, well-written, and mostly context. You want the specific lesson your team should absorb. This prompt extracts it.
THE PROMPT
I'm reading a postmortem and I want to extract the lessons that generalize to my own systems. Paste the postmortem below. Return exactly three sections: **1. Actual root cause (not the trigger)** Distinguish the trigger (what set it off) from the root cause (what let a normal trigger become an incident). Name both explicitly. **2. The fix that generalizes** The specific class of change that would prevent this kind of incident, not the one-off patch mentioned in the postmortem. Phrased as a design principle, not a code snippet. **3. The check that would have caught it earlier** A specific monitoring, alerting, or CI check my team could add. Include the actual signal to watch and the threshold that would fire before an incident, not after. No summary of the incident itself — assume I read it. Just the three sections. If any section can't be extracted from what's in the postmortem, say so honestly rather than invent. Postmortem: [PASTE POSTMORTEM HERE]
**Actual root cause (not the trigger)**
- Trigger: a routine config push increased the connection pool from 200 to 500 on the API service.
- Root cause: the downstream Postgres cluster's max_connections was 300 total across all clients; nothing prevented the config push from exceeding it. The system had no upper-bound enforcement on the trusted config path.
**Fix that generalizes**
Any config change that increases resource consumption on a downstream shared system must be gated by a bound expressed in that downstream system's own configuration. "The pool can't exceed what the DB says it accepts" should be a check, not a convention.
**Check that would have caught it earlier**
Alert on: (max_connections_configured across all clients) / (max_connections_allowed on DB) > 0.85. This would have fired at pool=255 (85% of 300), well before the incident. Add to the config-push CI as a pre-flight; also as a runtime metric.