Sentry

Sentry answers two triage questions. Enable either or both; they share one connection and token.

Role	Answers	How
Change source	Did something just ship?	Polls releases and deploys, records them as change events
Error source	Which exception is behind this alert?	Queries issues once per Incident at triage: exception, file:line, blast radius

• Read-only: AlertINT only sends GET requests. It never resolves issues or changes anything in Sentry.
• Off by default: with neither role enabled, AlertINT makes no Sentry calls.

Connect#

sentry:
  base_url: https://sentry.io     # host root; AlertINT adds the API path
  org: my-org-slug
  token_env: SENTRY_AUTH_TOKEN    # variable holding the token, never inline
  timeout_seconds: 10             # default

export SENTRY_AUTH_TOKEN="sntrys_..."

Token: create an Internal Integration (Settings → Developer Settings → Internal Integration) with only the scopes you need:

Scope	Needed for
project:read	Change source: releases and deploys
event:read	Error source: issues and their latest event

• The token is the boundary. The MCP tools can read any project the token can. Use a per-project token to limit what an agent reaches.
• Rate limits are per identity; the default polling stays well under them.

Base URL:

Deployment	base_url
Sentry SaaS (US)	https://sentry.io
Sentry SaaS (EU)	https://de.sentry.io
Self-hosted	https://sentry.your-company.internal

Change source: what shipped#

Sentry can't push deploys, so AlertINT polls for them and records each one as a change event, next to deploys your CI pushes.

sentry:
  # ...connection as above
  releases:
    enabled: true
    poll_interval_seconds: 60         # default
    initial_lookback_minutes: 60      # first run looks this far back
    release_scan_horizon_days: 30     # older releases aren't checked for new deploys
    projects: ["checkout", "payments"] # optional; omit for the whole org

changes:
  enrichment:
    enabled: true                     # required: this is what shows changes at triage and over MCP
  retention_days: 30                  # Sentry changes are pruned like all changes

Field	Default	Does
releases.enabled	false	Runs the poller
releases.poll_interval_seconds	60	How often to poll
releases.initial_lookback_minutes	60	First-run look-back
releases.release_scan_horizon_days	30	Oldest release still checked for new deploys
releases.projects	all	Project slugs to poll

What gets recorded:

• One change per new deploy. A release deployed to staging and production is two changes, each with its own environment.
• A release with no deploys is one release change.
• Exactly once, across polls and restarts.
• Labels: the Sentry project and environment. They match alert labels like any change event; unmatched recent deploys still show, ranked lower.

In triage: deploys appear in the Recent changes block, most relevant first, with a Δ6m before incident start hint and a link to the release.

When a poll fails (rate limit, network, 5xx), it's logged and retried next cycle. The sentry health check shows in the log and at GET /health.

Error source: what's erroring#

At triage, AlertINT asks Sentry which errors are firing for this service right now, and whether any is new.

Adds to triage	Why it matters
Exception + file:line (deepest in-app frame)	Points your coding agent at the line
Blast radius: level, affected users, in-window event rate	Calibrates severity
NEW vs chronic: first seen inside the Incident window, or before	NEW is a likely cause; chronic is more likely a symptom

• Bounded: one issue search plus at most max_issues event fetches per Incident.
• Once per Incident, at triage. Skipped when a known-issue rule short-circuits triage.
• Saved with the Finding, so the evidence pack shows exactly what the model saw.
• No match is a signal too: it suggests the problem isn't in application code.

sentry:
  # ...connection as above
  issues:
    enabled: true
    lookback_minutes: 30        # window before the first alert
    max_issues: 3               # top issues to include
    fetch_timeout_seconds: 15   # for the whole fetch; on timeout the section degrades
    live_window_minutes: 60     # default look-back for sentry_issues_list
    include_message: true       # include the exception message

Field	Default	Does
issues.enabled	false	Runs issue enrichment at triage
issues.lookback_minutes	30	How far before the first alert to look
issues.max_issues	3	Top issues to include
issues.fetch_timeout_seconds	15	Time budget for the whole fetch
issues.live_window_minutes	60	Default window for sentry_issues_list
issues.include_message	true	Include the exception message everywhere; false removes it from the prompt, storage, and MCP

Scoping#

From the Incident's shared labels	Used as
First of service, project, app, job	Sentry project (required)
environment or env	Environment (optional)

• Unknown project: noted as "no issues for this scope", not silently dropped.
• No project label: skipped, with the reason logged. AlertINT never guesses.

What leaves Sentry#

Sent to the LLM, stored, and shown over MCP	Never fetched
Exception type, culprit, in-app file:line	Local variables
Level, affected users, event rate, first/last seen, NEW flag	Request bodies
Exception message (only with include_message: true)	Breadcrumbs, user and context data

It all stays inside your boundary: your LLM, your database, your MCP server.

Infra vs application: the cross-source tag#

With the Error source on, each analyzed Incident gets one neutral headline in its Sentry section:

Tag	Means	Headline
matched	At least one new in-window error coincides with the alert	Sentry: N new in-window error(s) correlated.
infra-only	Sentry was checked; nothing new (maybe chronic ones)	Sentry: no new in-window errors for this scope
(none)	Sentry is off, or the query degraded	No headline

The tag is evidence for the model to weigh, not an instruction. infra-only always means "checked, nothing new", never "not configured".

MCP tools#

Tool	Answers	Available when
alertint_recent_changes	What shipped near this Incident? Includes Sentry deploys. See Change events.	Change enrichment is on
sentry_issues_list	What's erroring for a project (and environment), live, beyond the triage snapshot?	sentry.issues is on
sentry_issues_trace	Full stack traces for up to 10 issue IDs	sentry.issues is on

• Status filter: unresolved (default), resolved, or ignored (muted). Use the last two to ask "was this seen and handled before?"
• Window: without start/end, sentry_issues_list looks back live_window_minutes from now.
• Project and environment come straight from the Incident's saved Sentry section; no parsing.
• Per-ID errors don't fail a sentry_issues_trace batch.
• Same privacy shape: frames carry only relative filename, lineno, function, in_app. Absolute paths are dropped. Each result says the full event stays in Sentry.
• Links: Sentry's own issue URL, only when Sentry returns one.
• Untrusted text: culprits, function names, and messages can be planted by anyone who can trigger an error. Treat them as data, not instructions.

What's still erroring for checkout in prod right now?
Show me the full stack trace for the corroborating issue on this Incident.
Was this payments error seen before and already resolved or muted?