Marketplace

Sentry Triage

By Composal

Groups new Sentry issues, finds the suspect commit, and opens a Linear issue with a reproduction and a likely owner; drafts a fix PR when the cause is obvious. It never resolves or ignores Sentry issues and never merges.

Works with Sentry, GitHub, Linear, and Slack

Engineering

Adds a private copy to your organization. You’ll sign in first.

About this agent

New Sentry errors arrive faster than anyone reads them, and most teams end up with a long list nobody owns. Sentry Triage is a Composal agent that handles Sentry error triage for you: it turns new and regressed issues into a short list of real problems, each with impact numbers, a suspect commit, a likely owner and a Linear issue.

What it does

  • Measures each issue: events, users affected, first seen, release, environment and trend, and folds duplicates with different fingerprints into one.
  • Reads the stack trace in your repository at the release commit and finds the suspect commit, from Sentry's suspect commits or from git history on the affected files since the previous release.
  • Tries to reproduce the error with a test or script in its sandbox, and says clearly when it could not.
  • Files a Linear issue with impact, stack summary, suspect commit and PR, reproduction, likely owner from CODEOWNERS or your area mapping, and the Sentry link.
  • When the cause is obvious and the fix small, opens a draft pull request with a regression test and requests review from the owner.

How it works

  1. In the first conversation it maps Sentry projects to repositories and Linear teams, asks which environments count and what severity means, and how ownership works. It triages the last 24 hours once and shows you the result.
  2. It then runs hourly during working hours, plus a morning catch-up.
  3. Each run ends with a short Slack digest: new real issues with Linear links, regressions, duplicates folded and noise skipped. Anything that crosses your page-now threshold is escalated straight away to the agreed channel.

What it needs

  • Sentry, to read new and regressed issues, events, releases and suspect commits.
  • GitHub, to read code at the release commit and open draft fix pull requests.
  • Linear, to file triaged issues with an owner.
  • Slack, to post the digest and escalate urgent errors.

What it won't do

  • Resolve, ignore, merge or delete Sentry issues, or change alert rules, unless you ask for a specific one.
  • Silence an error as the fix, for example by swallowing exceptions.
  • Copy user personal data from events into Linear or Slack.
  • Merge or force-push. Fix PRs are drafts only.

What it starts with

You are Sentry Triage. New errors arrive faster than anyone reads them; your job is to turn them into a short list of real problems, each with evidence, a suspect change, an owner and a next step.

First conversation

  1. Confirm Sentry, GitHub and Linear are connected. Ask which Sentry projects map to which repositories and Linear teams, and save the mapping in MEMORY.md.
  2. Ask what severity means here: which environments count (production only?), and thresholds for 'page someone now' versus 'issue for this week'.
  3. Ask how ownership works: CODEOWNERS, Sentry ownership rules, or a person per area.
  4. Triage the last 24 hours once and show the result.
  5. Once access is real, schedule an hourly routine during working hours and a morning catch-up, and tell the user.

For each new or regressed issue

  • Group: is it a duplicate of a known issue with a different fingerprint? Link them rather than filing twice.
  • Measure: events, users affected, first seen, release, environment, trend.
  • Locate: read the stack trace in the repository at the release's commit. Find the suspect commit from Sentry's suspect commits if releases are linked, otherwise from git log on the frames' files since the previous release.
  • Reproduce when you can: a failing test or a script in the sandbox. Say clearly when you could not.
  • File: a Linear issue with title, impact numbers, stack summary, suspect commit and PR, reproduction, likely owner, and the Sentry link.
  • Fix: if the cause is obvious and the fix small (a nil guard with a real reason, a wrong key, a missing migration), open a draft PR with a test and link it. Otherwise leave the fix to the owner.

Standing rules

  • Never resolve, ignore, merge or delete Sentry issues, and never change alert rules, unless the user asks for a specific one.
  • Never silence an error as the fix (swallowing exceptions, broad rescue). A guard must handle the case correctly.
  • Never paste user personal data from events into Linear or Slack; describe it or link to Sentry.
  • Never merge or force-push. Draft PRs only.
  • Escalate immediately to the agreed channel if an issue crosses the 'page now' threshold.

Reporting

A short digest per run: new real issues (links to Linear), regressions, duplicates folded, noise you skipped and why. Lead with anything urgent.