---
name: sentry-error-triage
description: "Turns a pile of new production errors into a short list of distinct causes, marks which ones your code owns, and drafts a ticket for each. Use when a batch of fresh production errors needs sorting into causes, deciding which are the team's own bugs and filing tickets. Do not use for setting up error monitoring or investigating a single bug in depth. Related topics: devops, coding."
---

# Sentry Error Triage

Turns a pile of new production errors into a short list of distinct causes, marks which ones your code owns, and drafts a ticket for each.

## When to use

Use this skill when a batch of fresh production errors needs sorting into causes, deciding which are the team's own bugs and filing tickets. Do not use it for setting up error monitoring or investigating a single bug in depth.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Cluster the error list by shared failing frame or input, so each cluster stands for one cause.
3. Attach counts, affected users and first-seen timing to each cluster and relate them to the recent releases.
4. Label each cluster Ours, External or Unclear using the top in-app frame, and name the frame used.
5. Rank the Ours clusters by user impact and recency and choose the order to fix them.
6. Write one ticket per Ours cluster and one table row per External cluster explaining why it can be ignored.

## Inputs

- **Error list** (longer free text)
- **Stack traces** (longer free text)
- **Recent releases** (longer free text)
- **Our code lives in** (free text, e.g. "Folder names or package names")
- **Release under suspicion** (free text, e.g. "Version or none")
- **Ticket format** (choose one: Plain text, Markdown, Jira style)

## Output

A ranked table of clusters with owner label and impact, one ticket per owned cluster in the chosen format, and a short table of external noise with reasons.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Sentry Error Triage

Triage these new production errors.

- Error list: {{Error list}}
- Stack traces: {{Stack traces}}
- Recent releases: {{Recent releases}}
- Our code lives in: {{Our code lives in}}
- Release under suspicion: {{Release under suspicion}}
- Ticket format: {{Ticket format}}

Group errors by root cause, not by message: several titles often share one failing line or one bad input. For each group state the likely cause, the number of users or events affected, and when it first appeared relative to the releases. Decide ownership by the top in-app stack frame: Ours when it points into the listed code, External when it comes from a browser extension, a bot, a dependency or a third-party script, and Unclear when the trace is missing. Rank Ours groups by user impact and recency. Then write one ticket per Ours group with a title, evidence, a suspected fix, how to reproduce it, and an acceptance check. List External groups in a short ignore or filter table with the reason for each.

## Pitfalls

- Grouping by error message text, which splits one bug into five tickets and merges two different bugs that share a vague message.
- Blaming the latest release because it is the latest, when the first-seen time predates it.
- Filing tickets for browser-extension and bot errors, which burns engineering time on code the team does not control.