Bug triage

The automation reads new Sentry events on a tight cadence, groups genuine duplicates together, assesses severity from the signals that matter, how many users are hit, whether a payment or auth path is involved, and opens a Linear issue for anything new with the stack trace and context attached.

Your tracker starts to reflect reality: one issue per real bug, ranked by impact, with the noise collapsed.

Scoped access

• Sentry, read error events
• Linear, create and group issues

How it fails silently

Bug triage fails silently in two directions, and both look fine on the dashboard. It groups two errors with the same message but different root causes as one duplicate, so a brand-new failure hides inside a known issue and never gets its own attention. Or it scores severity by raw volume and marks a payment failure as low priority because it happened at 3am when traffic was light. The count looks managed, an issue exists, and meanwhile the outage that should have paged someone is sitting at the bottom of the backlog labeled minor.

What the overseer catches

After the issue is filed, the overseer looks again at the grouping and the priority against the actual errors. A payment or auth failure sitting at low priority, or two different stack traces merged as one duplicate, is the kind of call it catches, raising it for a human before the bug stays lost in the wrong bucket.

Routine, clearly-duplicate, clearly-minor errors are grouped and filed at the right priority with no input from you.

What reaches you is the close call: the error on a critical path, the ambiguous grouping, the new failure that does not fit a known pattern. Those land in your inbox flagged, so a real incident gets a human read instead of quietly sitting downgraded in the backlog.