# Error monitoring (Issues)

> https://docs.errora.org/en/products/issues

Issues are the core of Errora: every exception your app throws is normalized, fingerprinted
and grouped, so a thousand occurrences of the same bug are one row you can act on.

## Setup

Nothing beyond initializing the SDK — unhandled exceptions are captured automatically:

```python
import sentry_sdk
sentry_sdk.init(dsn="https://<public_key>@<host>/<project_id>", environment="production")
```

See [SDK setup](/en/platforms/overview) for your platform. To capture something you already
handled:

```python
try:
    charge(order)
except PaymentError as exc:
    sentry_sdk.capture_exception(exc)
```

## How grouping works

1. The event is **normalized** (stack frames, exception values, request, contexts, tags).
2. If it is minified JavaScript and you uploaded [source maps](/en/products/source-maps), it
   is **symbolicated first**, so grouping happens on stable original frames.
3. A **fingerprint** is computed from the exception type plus the meaningful stack frames.
4. Events with the same fingerprint collapse into one **issue**, which tracks `times_seen`,
   unique users, first/last seen, and its status.

An event arriving for an issue you already resolved **regresses** it back to unresolved and
fires the `issue.regressed` alert event.

## The issue list

**Issues** in the sidebar lists open issues for the selected project, newest activity first,
each with a 24h sparkline.

- **Search** — free text across the title and message, with word-prefix matching: `time`
  finds `timeout`.
- **Filters** — status (`unresolved`, `resolved`, `ignored`), environment, level, time period,
  and **user**: pick a person and the list narrows to the issues they hit. The same filter is
  built into requests, jobs and logs, and the **Users** page links straight into each of them.
- **Sort** — last seen, first seen, **occurrences** (the event count shown on every row) or
  users affected, so the most impactful issues come first.
- **Environment scoping** — the list shows the selected environment only; an issue's page then
  lists every other environment it also impacts.
- **Bulk actions** — select rows to resolve, ignore, reopen, archive, re-prioritize or assign
  them in one request.
- **Trends** — `GET /projects/{id}/issues/trends?period=24h|30d` powers the sparklines.

## The issue page

- **Stack trace** with syntax highlighting, the suspect frame highlighted, and surrounding
  source context for symbolicated frames.
- **Trend charts** — 24h and 30d.
- **Breadcrumbs** — including SQL statements with their bindings.
- **Request** — method, URL, headers, referrer.
- **Contexts and tags** — runtime, OS, browser, release, environment, plus your own tags.
- **Linked data** — [session replay](/en/products/session-replay),
  [user feedback](/en/products/user-feedback), the trace this event belongs to.

### Actions

| Action | Effect |
| --- | --- |
| Resolve | Closes the issue. A later event regresses it. |
| Ignore | Stops alerting without claiming it is fixed. |
| Archive | Hides it from the default list. |
| Bookmark | Personal star, per user. |
| Assign | Assign to a member of the organization. |
| Copy share URL | A link straight to this issue. |
| Create/link a GitLab issue | See [Integrations](/en/products/integrations). |
| AI auto-fix | Draft a patch and open a merge request — see [AI auto-fix](/en/products/ai-autofix). |

## Reducing noise

- **`before_send`** in the SDK — drop or scrub events client-side.
- **`ignore_errors` / `denyUrls`** — skip known-harmless exceptions and third-party scripts.
- **Project sample rate** — store only a fraction of arriving events (project settings).
- **Ignore** an issue rather than resolving it, when it is noise you can't remove yet.
- **Auto-resolve stale issues** — in project settings, resolve issues automatically after 7, 14
  or 30 days without a new event. A new event reopens them, exactly as with a manual resolve.

## API

```text
GET  /api/v1/projects/{project_id}/issues?q=&status=&environment=&user=&ordering=-times_seen
GET  /api/v1/projects/{project_id}/issues/{issue_id}
GET  /api/v1/projects/{project_id}/issues/environments
GET  /api/v1/projects/{project_id}/issues/users?q=&stats_period=7d
GET  /api/v1/projects/{project_id}/issues/trends?period=24h|30d
POST /api/v1/projects/{project_id}/issues/bulk
GET  /api/v1/projects/{project_id}/issues/{issue_id}/series
POST /api/v1/projects/{project_id}/issues/{issue_id}/resolve|ignore|archive|bookmark|assign
GET  /api/v1/projects/{project_id}/events/{event_id}
```

`user` takes `id:42`, `email:…`, `username:…`, `ip:…`, or a bare value matching any of them.

AI agents can do the same over [MCP](/en/products/mcp) with `list_issues`, `get_issue` and
`update_issue_status` — and reach performance issues with `list_performance_issues` /
`get_performance_issue`.

## Troubleshooting

| Symptom | Cause / fix |
| --- | --- |
| Two bugs share one issue | The fingerprint collapsed them — add distinguishing context, or set an explicit `fingerprint` in the SDK |
| One bug spread over many issues | Frames differ per run (paths with ids, minified bundles) — upload source maps and normalize paths |
| Minified JavaScript frames | Upload [source maps](/en/products/source-maps) for that exact `release` |
| Events accepted but not stored | Project `sample_rate` below `1.0`, or the wallet is past its credit line |
| Nothing at all | The SDK isn't reaching Errora — check for a `202` response, and see [SDK setup](/en/platforms/overview) |