Sentry Integration
Overview
Sentry error tracking integration for querying issues, events, and project data during Root Cause Analysis. Sentry is a REMOTE service. Use ONLY the query_sentry API tool. All data is accessed via the Sentry web API with the resource_type parameter.
Instructions
Tool Usage
query_sentry(resource_type=TYPE, query=QUERY, stats_period=PERIOD, project=PROJECT, limit=N)
Resource Types
'issues' -- Search issues. query is a Sentry search expression (e.g. is:unresolved level:error)
'issue_detail' -- Get metadata for one issue. query is the numeric Sentry issue ID
'issue_event' -- Get the latest event for an issue with full stacktrace + breadcrumbs + tags. query is the issue ID
'projects' -- List projects in the connected Sentry org
'events' -- Discover-style event table search. query is a Sentry search expression
Sentry Search Syntax
key:value -- exact match (e.g. level:error, environment:production)
AND / OR -- combine clauses (e.g. level:error AND environment:production)
!key:value -- negation
key:[a,b] -- value in list
>, <, >=, <= -- comparison on numeric/date fields
* -- wildcard
- Common keys:
level, environment, release, project, is, assigned, bookmarks, has
stats_period
- Format:
Nm minutes, Nh hours, Nd days, Nw weeks (e.g. 24h, 7d, 30m)
- Defaults to
24h if omitted
Common Searches
- Unresolved errors:
query_sentry(resource_type='issues', query='is:unresolved level:error', stats_period='24h')
- Production fatal errors:
query_sentry(resource_type='issues', query='level:fatal environment:production', stats_period='1h')
- Errors in a specific release:
query_sentry(resource_type='issues', query='release:v1.2.3 is:unresolved')
- Issue details:
query_sentry(resource_type='issue_detail', query='1234567890')
- Full stacktrace for an issue:
query_sentry(resource_type='issue_event', query='1234567890')
- All projects:
query_sentry(resource_type='projects')
- Events from a user:
query_sentry(resource_type='events', query='user.email:foo@example.com', stats_period='6h')
RCA Investigation Workflow
Step 1 -- Find the issue triggered by the alert:
If the alert webhook included an issueId, fetch the issue directly:
query_sentry(resource_type='issue_detail', query='ISSUE_ID')
Otherwise search recent unresolved issues:
query_sentry(resource_type='issues', query='is:unresolved level:error', stats_period='1h')
Step 2 -- Fetch the full stacktrace and breadcrumbs:
query_sentry(resource_type='issue_event', query='ISSUE_ID')
The response includes entries[].data.values[].stacktrace.frames, breadcrumbs, tags, user, release, and environment -- everything needed to identify the failing code path.
Step 3 -- Check the project context:
query_sentry(resource_type='projects')
Use this to map the Sentry project slug to a code repository or service.
Step 4 -- Look for related events in the same time window:
query_sentry(resource_type='events', query='project:PROJECT_SLUG environment:production', stats_period='1h')
This surfaces clustering -- whether the error coincides with other issues from the same release, environment, or user.
Step 5 -- Check if the issue is a regression:
Look at the issue's firstSeen and lastSeen in the issue_detail response. If firstSeen is recent and the affected release differs from the previous stable release, it's likely a regression.
Important Rules
- Sentry is a REMOTE service. Use ONLY the
query_sentry API tool.
- The
resource_type parameter is required and must be one of: issues, issue_detail, issue_event, projects, events.
- For
issue_detail and issue_event, the query parameter MUST be the numeric Sentry issue ID.
- Sentry tokens are read-only in Aurora -- never call mutating endpoints during RCA.
- Results are truncated at the output size limit. Use a more specific
query (e.g. add level:error, environment:production, or a release: filter) to narrow results when truncated.
issue_event payloads can be very large because they contain full stacktraces. Prefer issue_detail first; fetch the event only when you need the stacktrace.
1---2name: sentry3description: Sentry error tracking integration for searching issues, fetching stacktraces, listing projects, and running Discover event searches during RCA investigations4---56# Sentry Integration78## Overview9Sentry error tracking integration for querying issues, events, and project data during Root Cause Analysis. Sentry is a REMOTE service. Use ONLY the `query_sentry` API tool. All data is accessed via the Sentry web API with the `resource_type` parameter.1011## Instructions1213### Tool Usage14`query_sentry(resource_type=TYPE, query=QUERY, stats_period=PERIOD, project=PROJECT, limit=N)`1516### Resource Types171. `'issues'` -- Search issues. `query` is a Sentry search expression (e.g. `is:unresolved level:error`)182. `'issue_detail'` -- Get metadata for one issue. `query` is the numeric Sentry issue ID193. `'issue_event'` -- Get the latest event for an issue with full stacktrace + breadcrumbs + tags. `query` is the issue ID204. `'projects'` -- List projects in the connected Sentry org215. `'events'` -- Discover-style event table search. `query` is a Sentry search expression2223### Sentry Search Syntax24- `key:value` -- exact match (e.g. `level:error`, `environment:production`)25- `AND` / `OR` -- combine clauses (e.g. `level:error AND environment:production`)26- `!key:value` -- negation27- `key:[a,b]` -- value in list28- `>`, `<`, `>=`, `<=` -- comparison on numeric/date fields29- `*` -- wildcard30- Common keys: `level`, `environment`, `release`, `project`, `is`, `assigned`, `bookmarks`, `has`3132### stats_period33- Format: `Nm` minutes, `Nh` hours, `Nd` days, `Nw` weeks (e.g. `24h`, `7d`, `30m`)34- Defaults to `24h` if omitted3536### Common Searches37- Unresolved errors: `query_sentry(resource_type='issues', query='is:unresolved level:error', stats_period='24h')`38- Production fatal errors: `query_sentry(resource_type='issues', query='level:fatal environment:production', stats_period='1h')`39- Errors in a specific release: `query_sentry(resource_type='issues', query='release:v1.2.3 is:unresolved')`40- Issue details: `query_sentry(resource_type='issue_detail', query='1234567890')`41- Full stacktrace for an issue: `query_sentry(resource_type='issue_event', query='1234567890')`42- All projects: `query_sentry(resource_type='projects')`43- Events from a user: `query_sentry(resource_type='events', query='user.email:foo@example.com', stats_period='6h')`4445## RCA Investigation Workflow4647**Step 1 -- Find the issue triggered by the alert:**48If the alert webhook included an `issueId`, fetch the issue directly:49`query_sentry(resource_type='issue_detail', query='ISSUE_ID')`5051Otherwise search recent unresolved issues:52`query_sentry(resource_type='issues', query='is:unresolved level:error', stats_period='1h')`5354**Step 2 -- Fetch the full stacktrace and breadcrumbs:**55`query_sentry(resource_type='issue_event', query='ISSUE_ID')`5657The response includes `entries[].data.values[].stacktrace.frames`, breadcrumbs, tags, user, release, and environment -- everything needed to identify the failing code path.5859**Step 3 -- Check the project context:**60`query_sentry(resource_type='projects')`6162Use this to map the Sentry project slug to a code repository or service.6364**Step 4 -- Look for related events in the same time window:**65`query_sentry(resource_type='events', query='project:PROJECT_SLUG environment:production', stats_period='1h')`6667This surfaces clustering -- whether the error coincides with other issues from the same release, environment, or user.6869**Step 5 -- Check if the issue is a regression:**70Look at the issue's `firstSeen` and `lastSeen` in the `issue_detail` response. If `firstSeen` is recent and the affected `release` differs from the previous stable release, it's likely a regression.7172## Important Rules73- Sentry is a REMOTE service. Use ONLY the `query_sentry` API tool.74- The `resource_type` parameter is required and must be one of: issues, issue_detail, issue_event, projects, events.75- For `issue_detail` and `issue_event`, the `query` parameter MUST be the numeric Sentry issue ID.76- Sentry tokens are read-only in Aurora -- never call mutating endpoints during RCA.77- Results are truncated at the output size limit. Use a more specific `query` (e.g. add `level:error`, `environment:production`, or a `release:` filter) to narrow results when truncated.78- `issue_event` payloads can be very large because they contain full stacktraces. Prefer `issue_detail` first; fetch the event only when you need the stacktrace.