Collection
Find the failure without creating a second incident
Reduce a reproducible failure, locate its boundary and control the risks of retries, concurrent edits and recovery.
10 elements · Explore in any order.
2 checklists · 1 pattern · 5 protocols · 1 question · 1 template
10 elements
Shrink the example until the same failure is hard to hide
A thousand-line attachment is evidence. A six-line reproducer is an invitation to solve the problem.
Read the idea ProtocolBisect the version history instead of inspecting every change
The last edit is a suspect, not automatically the culprit.
Read the idea TemplateFind the first boundary where the record becomes wrong
Follow one record, not five dashboards reporting different populations.
Read the idea ProtocolKeep every rerun result when the failure is intermittent
Rerunning until green edits the story, not the software.
Read the idea ChecklistTrace the request by identity, not by nearby timestamps
Two messages appearing at 10:03 do not necessarily belong to the same story.
Read the idea PatternTreat a timeout as an unknown outcome before repeating the action
No reply is not the same as no action.
Read the idea ProtocolReuse the operation identity when retrying the same intent
A retry should not introduce itself as a brand-new business request.
Read the idea ProtocolMake the write conditional on the version you reviewed
A careful review of yesterday's value does not authorize overwriting today's change.
Read the idea QuestionReverse the business effect without restoring stale history
Undo is a business decision when other people have moved on.
Read the idea ChecklistGive the canary a fair comparison and a real stopping rule
Five easy successes can be a very convincing test of the wrong workload.
Read the idea