Tools / Sentry Incident Triage
Sentry Incident Triage icon

Sentry Incident Triage

Turn error evidence into a safe incident brief

Paid skills show the price before running, and failed paid calls do not charge.

Incident Triage turns a bounded set of error issues, events, projects, environments, and releases into a redacted review pack without changing incident state or code.

It orders issues using stored regression state, recency, affected-user count, and event count. It can inspect one representative event, compare first-seen timestamps around an explicit release boundary, and produce a next-check checklist while keeping root cause, ownership, and causation as unknown unless the evidence proves them.

What you can do

  • triage_issues — prioritize a bounded issue list with transparent evidence
  • inspect_issue — retrieve one issue and a redacted representative event
  • compare_releases — compare issue first-seen timestamps around a release
  • build_incident_brief — package top issues, scope, links, and unknowns
  • suggest_next_checks — produce a non-executing checklist from observed issue terms

Who it's for

Engineering leads, on-call developers, SRE teams, agencies, and founders maintaining production applications.

How to use it

  1. Select the organization, projects, environments, and a window no longer than 30 days
  2. Triage at most 100 issues and inspect only the candidates that need detail
  3. Compare an explicit release boundary without calling timing a root cause
  4. Use the brief and checklist for human investigation or a separate authorized code workflow

Getting started

Start with unresolved production issues from the last seven days. The tool never resolves, assigns, prioritizes, or edits issues; changes alerts or releases; downloads replays or attachments; edits code; or creates tickets and pull requests.

Permissions and setup

  • Sentry Organization Token (secret): Read-only organization token with event:read and project:read permissions for bounded incident evidence. Official setup
Triage IssuesPricing: paid

Order a bounded issue set using stored regression state, recency, affected-user count, and event count with transparent priority evidence.

Returns: A bounded issue queue with regression, recency, user, count, project, link, and scope evidence
Inspect Issue EvidencePricing: paid

Retrieve one exact issue and one selected representative event while removing sensitive request, user, credential, email, and IP data.

Returns: Redacted issue detail and one representative event with an explicit evidence boundary
Compare Release EvidencePricing: paid

Partition issue first-seen timestamps around one exact release boundary and label the result as timing correlation rather than causation.

Returns: Issues partitioned by an explicit release timestamp with before and after totals and causation limits
Build Incident BriefPricing: paid

Package the selected scope, issue evidence, top candidates, links, and unresolved questions into a bounded read-only incident brief.

Returns: A redacted incident brief with bounded scope, top issue evidence, and explicit unknowns
Suggest Next ChecksPricing: paid

Generate a non-executing investigation checklist from terms present in one exact issue without editing code or asserting root cause.

Returns: A non-executing, evidence-linked checklist with root-cause and mutation boundaries
Loading reviews...

Loading activity...

v0.012026-08-30
  • Initial read-only release with bounded issue triage, event redaction, release comparison, incident briefs, and next checks

Copy these instructions to use Sentry Incident Triage in Claude, ChatGPT, Copilot, and more.

What you can do with Sentry Incident Triage

Build a redacted post-release incident brief

Prioritize bounded production issues, inspect one representative event, and compare timing with an explicit release.

  1. Call `triage_issues` with one organization, selected projects and environments, and a window no longer than 30 days.
  2. Use `inspect_issue` for the strongest candidate and review the redacted representative event.
  3. Run `compare_releases`, then use `build_incident_brief` while keeping root cause and ownership explicit unknowns.

Related Tools

Related Categories

💻 Development🛡️ Security📊 Analytics

Frequently Asked Questions

How are Sentry issues prioritized?

`triage_issues` orders at most 100 issues using stored regression state, last-seen time, affected-user count, and event count, and returns the exact basis fields with the result.

What sensitive Sentry data is removed?

Issue inspection removes authorization and cookie fields, passwords, tokens, request bodies, email addresses, IP addresses, and user objects before returning representative event evidence.

Does compare_releases identify the root cause?

No. It partitions issue first-seen timestamps around one explicit release boundary and labels the relationship as timing correlation, never release causation.

Can Sentry Incident Triage resolve issues or edit code?

No. It never resolves, assigns, or edits an issue, changes an alert or release, downloads replays or attachments, edits code, creates a ticket, or opens a pull request.