Sentry Incident Triage

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

Select the organization, projects, environments, and a window no longer than 30 days
Triage at most 100 issues and inspect only the candidates that need detail
Compare an explicit release boundary without calling timing a root cause
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.

Information

Price: From $0.01
Billing: The final price is shown before running. Failed paid calls do not charge.
Provider: Sentry
Sentry Organization Token: Read-only organization token with event:read and project:read permissions for bounded incident evidence. · Get key

Example workflows

Build a redacted post-release incident brief

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

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

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.