Issues

An issue is not a single error — it’s a group of identical errors collapsed by fingerprint. Instead of a thousand rows of the same exception, the “Issues” section shows you one card with a “how many times this happened” counter and a chart of when.

How errors get into Gotcha

Issues are created automatically from events sent by your application’s SDK — Gotcha accepts them over the Sentry ingestion protocol (envelope/store), so any official Sentry SDK for your language works out of the box. Installing the SDK, finding your project’s DSN, and minimal initialization for Go/PHP/JavaScript/Python are covered in SDK and integrations. There’s no manual step to “create” an issue in the UI: as soon as the SDK sends an unhandled exception (or you explicitly call captureException), the first issue shows up within a few seconds.

List and filters

The section opens from the “Issues” entry in the left rail (bug icon) — a URL like /projects/<id>/issues. At the top is a filter bar (a plain form, works without JS):

By default the list opens filtered to status “unresolved” — you see what needs attention rather than the whole history; to look at closed ones, switch the status to “resolved”, “ignored”, or “all”.

The table shows, for each issue: level (badge), title and culprit, a 24-hour trend sparkline, event count (“Events”), when it was last seen, status, and the assignee. The list is paginated (25 issues per page), with “Prev / N of M / Next” navigation at the bottom.

Checking issues via the checkboxes on the left lets you apply a bulk action — “Resolve”, “Ignore”, or “Unresolve” — to several rows at once.

How grouping works

Every incoming event gets a fingerprint — a key that either places it into an existing issue or creates a new one. Computation priority (highest first):

1. Custom fingerprint from the SDK — if the application explicitly set a fingerprint on the event (including the special value {{ default }}, which substitutes the automatically computed part).
2. Normalized stack trace — if there’s an exception with a stack trace, the key is built from the frames’ modules/functions.
3. Exception type + normalized message — if there’s no stack trace but there is an exception (type + message with variable parts like numbers and IDs stripped out).
4. Normalized message — a plain message with no exception (e.g. captureMessage).

An event whose fingerprint has been seen before joins the existing issue: the “Count” goes up and “Last seen” is updated. A fingerprint that hasn’t been seen before creates a new issue with that event as the first one.

Because messages and stack traces are normalized, errors that are essentially the same but differ by numbers/IDs in the text (user 42 not found, user 43 not found) usually group into one issue, while exceptions of a different type or code location end up in different ones.

Issue detail

Clicking a row’s title opens /issues/<id>:

• Back link at the top (← Issues) returns you to wherever you opened the detail from — the issue list, an endpoint page, a trace, and so on; the label adapts to the source section. On a direct visit or a reload it goes to the project’s issue list.
• Title, culprit, a level badge, and a status badge.
• Metadata: First seen / Last seen / Times seen.
• Action buttons (see below) and an assignee form.
• Frequency chart — a bar chart of event counts across the selected time range (the page has the shared period control, default 7 days), in up to 57 bars; the bar width adapts to the window (3-hour bars at the 7-day default). On windows shorter than ~4h40m the step floors at 5 minutes, so you get fewer bars.
• Recent events — a table of the 20 most recent events for this issue: when, message, environment, release. Clicking the timestamp opens that event’s detail (?event=<id> in the URL, the row is highlighted).

Reading the frequency chart

Each bar is the number of events in one time bucket (3 hours at the default 7-day window). A flat, low background with occasional single bars usually means the error is one-off or very rare. A single sharp spike points to a short-lived incident (an outage in a third-party service, or one bad deploy that got rolled back). A steadily climbing “staircase” of bars is a sign of an ongoing degradation that won’t fix itself — worth acting on right away, not just waiting for an alert.

Event detail

With an event selected, the page shows a block with:

• Stack trace — frames from your application’s own code (in-app) are shown in full right away: file path with line number, function, module. Frames from frameworks/runtime/dependencies (not in-app) are collapsed into a <details> element — by default only the function (file:line) summary line is visible, and the full frame expands on click. This separates your code from library noise right in the stack trace.
• Trace link — if the event has an associated trace_id (the request was part of a traced transaction), a “View trace” link to the waterfall in Performance is shown.
• HTTP request — if the event happened while handling an HTTP request, a “Request” card is shown: the METHOD URL line, query-string parameters, the body, and (collapsible) headers. Sensitive data is stripped at ingest (see Privacy) — it’s in neither storage nor the UI.
• Tags — arbitrary key-value pairs the SDK attached to the event.
• User and SDK — the user’s id/email/IP (if the SDK sent them) and SDK information.
• Contexts — raw structured data from the event (runtime environment, device, etc. — whatever the SDK sent).

Copy for AI

For the currently selected event, two buttons — “Copy (Markdown)” and “Copy (Text)” — put the full error context on the clipboard in one shot: exception type and message, the full stack trace (files, lines, functions), the HTTP request (method, URL, query string, headers, body), contexts, tags, and this event’s breadcrumbs. The Markdown format is handy when pasting into a chat that renders markdown itself; the plain-text format is for when you just need plain text. It saves copying the pieces by hand when you want a quick fix suggestion from a model.

Warning: the dump includes request and context data for the event (headers, request body, tags, contexts) and is meant to be pasted into an external AI model (a chat, an assistant, and so on). If your project’s events may contain sensitive or personal information, don’t paste the dump into untrusted services — check first that sensitive data is stripped at ingest (see Privacy), or clean up the text by hand.

Actions

An issue can be resolved (marked fixed), ignored (hidden without marking it fixed — useful for known noise), or unresolved again. A separate form assigns the issue to any project member; assigning doesn’t change the status, it’s just “who’s on it.”

Alerting on new issues

Instead of checking the list by hand, set up a “new issue” alert rule in Alerts — the team gets notified on the channel of your choice (email/webhook/Telegram) as soon as an issue that didn’t exist before shows up.