Sentry Error Triage Agent

Sentry is very good at telling you something broke and very bad at telling you whether it matters, so teams end up either filing everything or filing nothing. This agent reads the issue, its recent events and your release history, scores it against the severity rules you write, and files one Linear ticket with the impact numbers, the failing frame and the suspected release already in it. Engineers get a ticket they can start on, and the alert channel only rings at the top of your scale.

What people use it for

• Catch the bad deploy - When an error first appears minutes after a release, the agent names that release in the ticket and, if your rules call it severe, in Slack. The link between the deploy and the spike is made while it still matters.
• One ticket per bug - Linear is searched for the same error signature before anything is filed, so a recurring error links back to the ticket that already exists instead of stacking three duplicates in the backlog.
• Tickets with the evidence in them - Impact, location, stack, first and last seen and the suspected release are written into the issue body in a fixed order, so nobody has to open Sentry to decide whether to pick it up.
• Separate noise from severity - Nine events from three users on a nightly job is not two thousand events on checkout. Your severity rules make that call every time, and only the top level is allowed to interrupt anyone.

Before you fork

What do I need to connect before this works?

A Sentry credential with read and write on issues in the projects you want triaged, a Linear key for the team you file into, and a Slack channel for severe errors. Your severity thresholds and a short description of the services and their owners go in as variables. Nothing about your existing alert rules changes except which of them you forward here.

What does it cost to run, on a noisy project?

It runs on the errors your Sentry rule sends, so the volume is yours to set. A rule that fires on new issue groups rather than on every event keeps this to a handful of runs a day even on a busy service. Start with one project, watch a day, then widen.

Can it close or hide errors I still need?

No. It never resolves, ignores, merges or deletes a Sentry issue, and the only write it makes there is linking the Linear key back in. It reports evidence rather than a diagnosis, so it will tell you which frame throws and which release it started after, and it will not name a cause or a commit. When an error sits between two severity levels it takes the lower one and says why, so the channel stays quiet by default.