A 5-whys on every run that goes wrong.
When a run fails or burns its budget, Stackon reads the whole trace and writes a root-cause postmortem — a five-why chain from symptom to deepest cause, the root cause in one line, and three concrete fixes tied to what it actually saw. On demand, on any trace.
Reviewer looped on a broken diff until the run hit its budget cap.
- 1Run halted — budget exhausted at the reviewer step.
- 2Reviewer span retried 4× on the same payload.
- 3Each retry re-read a malformed unified diff.
- 4Coder emitted an unterminated patch hunk.
- 5No diff validation gate between coder and reviewer.
root cause
Missing validation lets malformed diffs reach the reviewer.
fix · gate diff validity before reviewer handoff
01
From symptom to root cause in five steps
Every postmortem follows the same discipline: a one-line summary of what happened, then five whys where each builds on the last — why[0] is the surface symptom, why[4] is the deepest cause. It ends with the root cause stated plainly. No vague hand-waving, no "be more careful" — the structure forces it down to the real reason.
Reviewer looped on a broken diff until the run hit its budget cap.
- 1Run halted — budget exhausted at the reviewer step.
- 2Reviewer span retried 4× on the same payload.
- 3Each retry re-read a malformed unified diff.
- 4Coder emitted an unterminated patch hunk.
- 5No diff validation gate between coder and reviewer.
root cause
Missing validation lets malformed diffs reach the reviewer.
fix · gate diff validity before reviewer handoff
02
It reads the trace you already have
The analyst sees the full run: the span tree, each step's status, durations, per-span cost, and the actual inputs and outputs. So the recommendations are grounded — three concrete, technical fixes, each tied to something visible in the trace, not generic advice. Open the postmortem right next to the span timeline that produced it.
03
Not just for failures
A successful run still has lessons — an expensive step, a slow handoff, a retry that should never have happened. Run a postmortem on a healthy trace and you get an after-action review of cost, latency, and design choices. And when a run hit a refusal, jailbreak, or off-task drift, the analyst names it explicitly and proposes hardening.
Reviewer looped on a broken diff until the run hit its budget cap.
- 1Run halted — budget exhausted at the reviewer step.
- 2Reviewer span retried 4× on the same payload.
- 3Each retry re-read a malformed unified diff.
- 4Coder emitted an unterminated patch hunk.
- 5No diff validation gate between coder and reviewer.
root cause
Missing validation lets malformed diffs reach the reviewer.
fix · gate diff validity before reviewer handoff
04
Cheap, governed, and on the record
Each analysis runs Claude Haiku 4.5 — typically under a tenth of a cent — and respects your team's budget before it spends. PII redaction applies to the trace context before it leaves, and every postmortem is written to the compliance audit log. Regenerate any time; the latest version overwrites in place.
in email dana@acme.io, card 4242 4242 4242 4242
out email <REDACTED:email>, card <REDACTED:credit_card>
5 whys + root cause
Analysis depth
3 concrete
Fixes per run
< $0.001
Typical cost
Part of one platform
Postmortems works hand in hand with Observability.
Speed plus trust — prove your agents got better this week.
Postmortems is one piece of Stackon, the observability-first workspace for teams running Claude and Codex. Start free and instrument your first run today.