> ## Documentation Index
> Fetch the complete documentation index at: https://sentrydocs.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Issues & Events
> How Sentry groups errors into issues and tracks individual occurrences as events.
Sentry captures individual error occurrences as **events** and automatically groups related events into **issues**. This distinction is fundamental to how you triage and resolve problems in your application.
## Events
An event is a single occurrence captured by the Sentry SDK. Every time an error is thrown, a transaction completes, or a session is recorded, Sentry receives one event.
Each event contains:
* **Stack trace** — the call stack at the moment the error occurred
* **Breadcrumbs** — a log of actions that led up to the event (navigation, clicks, network requests, console output)
* **Context** — runtime information like OS, browser, app version, and device
* **Tags** — key-value pairs you attach to categorize and filter events
* **User** — identity of the affected user (if configured)
* **Request** — HTTP request details for server-side events
### Event types
| Type | Description |
| ----------------- | -------------------------------------------------------------------- |
| **Error** | An exception or unhandled error in your application |
| **Transaction** | A performance trace measuring the duration of a request or operation |
| **Profile** | A sampling profile of function-level performance |
| **Replay** | A session replay capturing user interactions in the browser |
| **Cron check-in** | A heartbeat from a scheduled job or cron monitor |
| **Feedback** | User-submitted feedback attached to a session |
## Issues
An issue is a group of events that Sentry considers to be the same problem. When Sentry receives an event, it computes a **fingerprint** based on the error type, message, and stack trace, then looks for an existing issue with the same fingerprint. If one exists, the event is added to it. If not, a new issue is created.
This grouping means you see "this error has occurred 1,243 times across 87 users" rather than thousands of individual entries.
### Issue types
Sentry detects many types of issues across different categories:
**Error issues**
* Unhandled exceptions and crashes
**Performance issues** (detected automatically)
* N+1 Query
* Slow DB Query
* Consecutive DB Queries
* DB on Main Thread
* File I/O on Main Thread
* Large Render Blocking Asset
* Uncompressed Asset
* Large HTTP payload
* Consecutive HTTP
* N+1 API Call
* HTTP/1.1 Overhead
* Endpoint Regression
* Function Regression
**Frontend issues**
* Rage Click Detected
* Hydration Error Detected
* Web Vitals
**Mobile issues**
* File I/O on Main Thread
* Image Decoding on Main Thread
* JSON Decoding on Main Thread
* Regex on Main Thread
* Frame Drop
**Cron issues**
* Missed check-ins, failed jobs, and timeout violations
**Feedback**
* User-submitted crash reports and feedback
### Issue lifecycle
Issues move through states as you investigate and resolve them:
The issue was just created — Sentry has never seen this fingerprint before. New issues surface at the top of the issue stream by default.
The issue continues to receive events and has not been resolved or archived. Most active issues are in this state.
Sentry detected that the issue's event volume increased significantly after a period of quiet. Escalating issues are surfaced prominently in the UI.
Someone marked the issue as resolved, or it was automatically resolved after a configured period without new events. If the same error recurs, the issue reopens as a **regression**.
The issue was previously resolved but new events arrived. Regressions are a signal that a fix didn't fully work or the problem came back in a new release.
The issue is muted — either until it escalates, until a condition is met, or indefinitely. Archived issues do not appear in the default issue stream.
### Issue priority
Sentry automatically assigns a priority to each issue based on signals like error frequency, number of affected users, and escalation patterns.
| Priority | When assigned |
| ------------ | ----------------------------------------------------------------------------- |
| **Critical** | Highest severity — high volume, widespread user impact, or rapidly escalating |
| **High** | Significant impact, requires prompt attention |
| **Medium** | Moderate impact; default for most new issues |
| **Low** | Minimal impact or rare occurrence |
You can manually override the priority on any issue.
## The issue detail page
When you open an issue, you see a consolidated view of everything Sentry knows about it:
* **Event count and user count** — how often it's occurring and how many users it affects
* **First seen / Last seen** — the time range of the issue
* **Stack trace** — the most recent event's stack trace, with source code inline if source maps or debug symbols are configured
* **Breadcrumbs** — the sequence of events leading up to the crash
* **Tags** — aggregated tag values across all events (useful for finding patterns like "this only happens on Chrome 120")
* **User** — the affected user for the current event
* **Similar issues** — related issues that may be caused by the same root problem
* **Activity** — a history of comments, status changes, and assignments
## Searching and filtering issues
The issue stream supports a query language for narrowing down issues:
```
is:unresolved assigned:me
is:unresolved !has:release
is:unresolved times_seen:>100
is:unresolved user.email:user@example.com
```
You can filter by status (`is:unresolved`, `is:resolved`), assignee, release version, environment, tags, and many other attributes. Saved searches let you bookmark commonly used filters.
Use the **Environment** selector at the top of the issue stream to filter events by environment (production, staging, etc.) without changing your search query.