Build a Sentry Error Triage Prompt That Classifies and Dedupes Noise

A production error lands in Sentry. Then ten more, half of them the same stack trace fired by the same broken deploy, the rest unrelated noise that's been firing for a month. Someone has to decide what's urgent, what's a duplicate, and what's safe to mute. A Sentry error triage prompt does that first pass for you: it classifies severity, collapses duplicates, and emits a verdict you can act on instead of a wall of red.

The pages that rank for this query mostly sell you a tool. Sentry's own cookbook wires up a resolution bot. A vendor post pitches an automated agent. Those work if you live inside one platform. A reusable prompt does something different: it runs on the error payload you paste into whatever model you have open, so the same triage logic works across Sentry, raw logs, or a crash report.

What error triage actually decides

Triage is a routing decision, not a fix. Given an error, you're answering four questions: how bad is it, has it shown up before, what probably caused it, and where does it go now. The model is good at all four if you force the answers into a contract instead of letting it ramble.

Severity is the part people get wrong. Stack frequency isn't severity. An error that fires 4,000 times an hour from a retry loop on a non-critical background job is lower priority than one that fires twice from the checkout path. The prompt needs the affected surface as a signal, not just the count.

Here's the take worth defending: most error noise isn't a model problem, it's a dedupe problem. Teams drown because the same root failure shows up as eight distinct issues with slightly different messages. A triage prompt that compares stack signatures against a list of known issues kills more noise than any severity heuristic. Dedupe first, classify second.

What you can do with this prompt

• Classify a Sentry issue as critical, high, low, or noise against the affected surface
• Compare a new error's stack signature to recent known issues and flag duplicates
• Emit a one-line likely-cause hypothesis from the stack trace and breadcrumbs
• Route each issue: fix now, backlog with a label, or mute with a reason
• Batch a list of issues into a single ranked triage table
• Draft the issue comment that explains the verdict to whoever picks it up

Anatomy of the triage prompt

Three parts again. Variables carry the error payload and the known-issue list. Instructions set the severity rubric and the dedupe rule. The contract locks the verdict format.

Variables → Prompt → Output

{{error_payload}}      the Sentry issue: title, stack, breadcrumbs, count
{{affected_surface}}   what user flow this touches (checkout, login, none)
{{known_issues}}       recent open issues to dedupe against
{{environment}}        prod / staging

→ Severity rubric + dedupe rule →

→ Output contract:
   Severity: critical | high | low | noise
   Duplicate of: <issue id or "new">
   Likely cause: <one line from the stack>
   Route: fix-now | backlog | mute
   Reason: <one sentence>

Keep the contract tight. A triage verdict that runs five paragraphs defeats the purpose. The whole value is a glanceable decision per issue, so the output contract caps each field at a line.

Step-by-step usage

1. Gather inputs

Copy the issue from Sentry: title, the top stack frames, breadcrumbs, and the event count. Pull your last dozen open issue titles or fingerprints into {{known_issues}} so the dedupe pass has something to match against.

2. Fill variables

Set {{affected_surface}} honestly. This is the field that separates real severity from raw frequency. "none" for a background job, "checkout" for anything a paying user touches.

3. Run the prompt

Low temperature again. Triage is classification, and you want the same error to get the same verdict whether you run it now or after lunch. Reproducibility is the point.

4. Post-process

Spot-check the dedupe calls. Models occasionally mark two errors as duplicates when they share a generic frame like a framework entry point but diverge higher up. Read the divergent frame before trusting a dedupe verdict on a critical-surface error.

5. Iterate

If everything comes back "high", your rubric is too coarse. Tighten the surface definitions in the prompt so background noise lands as "low" or "noise" instead.

Prompt-craft patterns that matter here

The dedupe-first ordering. Put the dedupe comparison before the severity step in the instructions. If the model classifies first, it spends effort grading an error that turns out to be a known duplicate. Dedupe, then only classify the survivors.

Step 1: Compare the error's top stack frames to {{known_issues}}.
        If the signature matches, set "Duplicate of" and stop grading severity.
Step 2: For new issues only, assign severity using {{affected_surface}}.

The mute-with-reason rule. Never let the prompt output a bare "mute". Force a reason. A muted error with no recorded reason becomes a mystery in three weeks when it starts firing again and nobody remembers why it was silenced.

Variables you'll set

Getting started

1. Copy the prompt into your model and set a low temperature.
2. Paste the Sentry issue into {{error_payload}} with stack and count intact.
3. List recent open issues in {{known_issues}} so dedupe has a baseline.
4. Set {{affected_surface}} to the real user flow.
5. Run it and read the dedupe verdicts before the severity ones.
6. Apply the route: fix-now, backlog, or mute with the recorded reason.
7. For a batch triage that ranks a whole inbox, start from the Production Error Triage Agent Pack.

Running triage on a single error is fine occasionally. Running it on the morning's full issue list is where a maintained pack earns its place, because the batch contract and the dedupe baseline are already wired.

A clean triage feeds straight into incident work when something does turn out critical, so it pairs with the blameless incident postmortem prompt. And if you're weighing a free prompt list against a maintained pack with a versioned contract, how to choose a reusable AI prompt pack covers that decision. The Incident Postmortem Agent Pack is the natural next step once a triaged error escalates.