# Issues

> Exceptions from the telemetry you already send, parsed and grouped into tracked issues you can hand straight to your coding agent.

An issue is a group of exceptions that share a root cause. Fixter reads the exceptions
already in your telemetry, parses their stack traces, and collapses the repeats into one
tracked issue with a count, a culprit, and a history. Then it hands you a way to fix it:
from any issue you can copy a ready-to-run command for your coding agent.

Issues live under [Issues](https://app.fixter.dev/issues) in the app.

## Nothing to set up

Issues are built from the telemetry you already send. Fixter watches your
[logs and traces](/using-fixter/telemetry/) for records that carry an exception, so any
error your services report through OpenTelemetry becomes an issue. There is no separate
error-reporting SDK, no new endpoint, and nothing to add to your code. If telemetry is
flowing, issues appear, including for exceptions that were reported before the feature was
turned on.

## How exceptions become one issue

A single bug throws the same exception thousands of times. Fixter parses each exception's
stack trace and groups every occurrence that shares a root cause into one issue, so you
see one row with a count of 3,412 rather than 3,412 separate lines. Parsing covers JVM,
Python, Node, .NET, and Ruby stacks, plus common database error formats, and each issue
is tagged with the runtime it came from.

## What an issue tells you

Each issue carries the facts you need to judge and place it:

- **Exception type and message**, and the **culprit**: the first frame in your own code,
  so you know where to look before opening anything.
- **Service** and **runtime** (JVM, Python, Node, .NET, Ruby, C++).
- **How much and how long**: the event count, when it was **first seen** and **last
  seen**, and a daily trend so you can tell a steady background error from one that is
  spiking.
- **Occurrences**: the individual times it fired, each with its full stack trace, log
  level, exception message, and a link to the trace and log it came from.

<!-- fx-image: the Issues list, showing exception type, service, runtime tag, count, and status -->

## Statuses

An issue's status is worked out from when it was seen, so it updates on its own:

| Status | What it means |
| --- | --- |
| New | First seen within the last 7 days |
| Ongoing | Seen before this week and still occurring |
| Regressed | Came back after at least 7 quiet days |
| Resolved | Marked resolved and no longer counted as active |

Regressed is the one to watch: it is an error you had probably stopped thinking about
returning after a week of silence.

## Hand an issue to your coding agent

Open an issue and copy its **Fix in Claude Code** command. It is a complete
`claude "..."` command, already filled in with everything the issue knows: the service,
the exception and its culprit frame, the in-app stack frames from a real occurrence, the
event count and trend, and the trace and log ids. Paste it into your terminal in the
repository and your agent starts from the root cause instead of from a blank prompt.

The command also tells the agent how to pull live detail through the
[Fixter MCP tools](/reference/mcp-tools/) if you have them connected: `get_trace` for the
full distributed trace behind the exception, `get_log` and `get_log_neighbors` for the
raw record and what surrounded it, and `run_sql` for anything broader. So the agent can
reproduce the failure from your real telemetry, not just the snapshot in the prompt.

<!-- fx-image: an issue detail page with the stack trace and the Fix in Claude Code button -->

## Where issues fit

Issues are the middle of the loop, not the end of it:

- **Alerts.** A new or regressed issue is exactly the kind of thing worth paging on.
  Fixter's [detectors](/using-fixter/alerting/) already alert on error bursts without any
  rule from you, and you can write rules of your own on the same signals.
- **Investigations.** When an alert lands in a Slack channel Fixter watches, it is
  [investigated automatically](/using-fixter/investigations/): an agent queries your
  telemetry and replies with root cause and blast radius, the same telemetry an issue is
  built from.

So an issue is rarely where you start looking and never where you have to stop: alerts
bring it to you, investigations explain it, and the Fix in Claude Code handoff closes it.

## Related

- [Telemetry](/using-fixter/telemetry/): the logs and traces issues are built from
- [Alerts](/using-fixter/alerting/): getting paged when an issue is new or regresses
- [Investigations](/using-fixter/investigations/): automatic root cause after an alert