Sentry Issue Resolver

Establish the failure from live event evidence, then trace it through the relevant source. An analysis request ends with findings and a proposed fix; implement when the user requests a fix. Do not change Sentry issue status without authorization.

Obtain evidence

Use an available authenticated Sentry connector, or the REST API below. Resolve the organization and issue from the supplied URL; preserve the host for self-hosted installations.

For REST, check prerequisites without displaying credentials:

command -v curl
test -n "$SENTRY_AUTH_TOKEN"

If authentication is missing, explain how to configure it without asking the user to paste the token into chat. Do not log authorization headers.

Set SENTRY_BASE_URL to the supplied installation's base URL, including the scheme and any path prefix, without a trailing slash (for hosted Sentry, https://sentry.io). List issue events and retrieve a relevant full event:

SENTRY_BASE_URL="<SENTRY_BASE_URL>"
curl --fail-with-body --silent --show-error \
  "$SENTRY_BASE_URL/api/0/organizations/<ORG_SLUG>/issues/<ISSUE_ID>/events/" \
  -H "Authorization: Bearer $SENTRY_AUTH_TOKEN"

curl --fail-with-body --silent --show-error \
  "$SENTRY_BASE_URL/api/0/organizations/<ORG_SLUG>/issues/<ISSUE_ID>/events/<EVENT_ID>/" \
  -H "Authorization: Bearer $SENTRY_AUTH_TOKEN"

Honor any requested event, environment, or time window. Use additional events or pagination when needed to establish a pattern; do not infer frequency or affected-user counts from a single sample.

Inspect the actual response schema. In issue-event REST responses, exception data is under entries[] where type == "exception"; do not assume the SDK's top-level exception.values shape. For a saved response:

jq '.entries[] | select(.type == "exception") | .data.values[] |
  {type, value, frames: .stacktrace.frames}' "<EVENT_JSON>"

Keep event ID/time, release, environment, transaction, breadcrumbs, and relevant request context with the stack trace. Share only the contextual fields needed to explain the failure.

Diagnose and fix

• Compare the event's deployed release with the inspected source. A merged fix may not have reached the affected worker or frontend release.
• Follow application frames and callers to establish the triggering input or state. Inspect the frame data instead of assuming the first frame is the throw site.
• Separate confirmed evidence from hypotheses and state what would distinguish competing explanations.
• For a requested fix, preserve existing contracts, make the smallest supported change, and run proportionate validation. Distinguish local verification from deployment or production recovery.

Report the failure, trigger and impact, cause with code locations, and the fix or next diagnostic step. Avoid filling a fixed report template or manufacturing a second solution.

API references

Consult these when adapting an API call:

• List an issue's events
• Retrieve an issue event