Triaging production errors
error-triageFREEerrorsproduction
Turns four hundred open issues into a list of three — and explains why the rest do not count.
Was er tut
- Triggers on pasted logs, an issue list from a tracker, “what do we fix first”, “the tracker is full of noise”.
- Sorts by two numbers together: how many people were hit and what it cost them. One user in a retry loop generates ten thousand events and matters less than an error that hit forty people once.
- Separates four kinds: a real defect, a hostile or malformed request, somebody else's outage, and noise you created yourself.
- For an outage it changes the question: not how to stop it, but what your code does while it lasts — retry, fail closed, or lie to the user.
- Requires reading one real occurrence in full rather than the aggregate: the aggregate hides what made this request different from the ten thousand that worked.
- Looks at what happened just before: the exception is often the second event, and the first was a warning grouped separately.
- Requires saying out loud what you are choosing not to fix, and removing it from the error level — otherwise the list becomes unreadable again.
- Forbids pasting tokens, emails or request bodies from the logs into the report.
Wozu er gut ist
A tracker with four hundred open issues is the same as one with zero: nobody reads either. Sorting by event count makes it worse — it floats one user with retries to the top. Count people and consequences instead, and demote the rest out of the error level, or the same pile returns within a month.
Wohin damit
- 1Legen Sie im Projekt den Ordner .claude/skills/error-triage an
- 2Legen Sie dort eine SKILL.md mit dem Text unten ab
- 3Fertig. Claude Code lädt den Skill selbst, sobald eine Aufgabe zur Beschreibung passt
Damit der Skill in allen Projekten statt nur in einem funktioniert, legen Sie ihn in ~/.claude/skills statt in den Projektordner.
SKILL.md-Datei
--- name: error-triage description: Turn a pile of production errors into a short list of things worth fixing. Use when the user shares logs or a Sentry issue list, asks what to fix first, or says the error tracker is full of noise. --- # Sorting production errors An error tracker with four hundred open issues is the same as one with zero: nobody reads either. The job is to get to a list of three. ## Group before you read Errors come in duplicates. Group by the message with the variable parts removed, then sort by two numbers together, never one: - **How many people** hit it — not how many events. One user in a retry loop can generate ten thousand events and matter less than an error that hit forty people once. - **What it cost them.** A failed payment, a lost draft, a blocked login are different in kind from a broken image. The top of that list is usually four or five issues. Everything below is noise until those are gone. ## Classify each one **A real defect.** Reproduce it, then hand it to root-cause debugging. **A hostile or malformed request.** A bad path, a malformed token, a bot. Not a defect — the defect is that it is logged as an error. Answer it correctly and log it at a level nobody is paged for. **Someone else's outage.** A dependency timing out. The question is not how to stop it but what your code does when it happens: does it retry, does it fail closed, does the user see something honest. **Noise you created.** An exception used for flow control, a caught error re-thrown one layer up and logged twice, a health check hitting a route that does not exist. ## Read one real event fully Not the aggregate — one actual occurrence, with its input, its user's state and its timestamp. Aggregates hide the thing that made this request different from the ten thousand that worked. Check what happened just before, too. The exception is often the second event; the first one was a warning nobody grouped it with. ## What to do with the rest Say plainly which issues you are choosing not to fix and why. Then make them stop being errors — downgrade the level, handle the case, or filter it — so the list stays readable. An issue left open and ignored trains everyone to ignore the list. ## Report Three issues, in order, each with: how many people, what it costs them, the suspected cause, and the next concrete step. Then one line on what was noise and what you did about it. Never paste tokens, emails or request bodies from the logs into the report. Report the ids.