Asking for a summary
The same document, the same model. The weak version returns the article rearranged; the strong one returns something you can act on, because it says who reads it and what they have to decide.
Tested on Claude Sonnet · 4.5 ·
Can you summarise this incident report?Summarise the attached incident report for the engineering leads who were not on call.
They need to decide whether to change the deploy process this quarter. Give me:
- What broke, in two sentences, no jargon
- The chain of events, as a timeline with times
- What made it worse than it needed to be, separated from what caused it
- Two changes that would have prevented it, with the cost of each
Skip anything the reader cannot act on. If the report does not say what caused it, say so rather than guessing.What broke: a schema migration locked the orders table for 14 minutes during peak traffic. Checkout returned 500s for the duration.
Timeline:
09:41 migration starts, lock acquired
09:43 checkout error rate crosses 5%, no alert fires
09:52 first customer report in support
09:55 on-call paged manually by support lead
09:58 migration killed, lock released
Cause: the migration added a column with a default, which rewrote the table under an exclusive lock.
Made it worse: the alert threshold was set on average latency, not error rate, so nothing fired for 12 minutes. The runbook had no entry for killing a migration.
Prevented it:
1. Add the column nullable, backfill in batches. Costs one extra deploy.
2. Alert on checkout error rate above 1% for 60 seconds. Costs an afternoon.The difference is not politeness or length. It is that the second version names a reader, a decision and a shape. Nothing else changed.
Notes from the author
The clause that does the most work is "separated from what caused it". Incident reports blur cause and aggravating factors, and asking for them apart forces the model to commit to a position instead of listing everything that went wrong in order.
Tagged