Issues

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 in the app.

Nothing to set up

Issues are built from the telemetry you already send. Fixter watches your logs and traces 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.

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 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.

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 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: 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.

Telemetry: the logs and traces issues are built from
Alerts: getting paged when an issue is new or regresses
Investigations: automatic root cause after an alert