Issues

An issue is a group of errors that share a root cause. Fixter reads the errors already in your telemetry, parses their stack traces, and collapses the repeats into one tracked issue with a count, a culprit, and a history. Each new issue is investigated automatically, so by the time you look at one it usually already carries a root cause. From there you can hand it to your coding agent.

Ask your agent for list_issues to see what is broken, or open 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 error, so anything 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.

How many errors become one issue

A single bug throws the same exception thousands of times. Fixter parses each 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.

Errors that differ only by an id stay together: Order 8f2c1a not found and Order b31e07 not found are one issue with a count of two, not two issues. The same goes for timestamps, request ids, and anything else that changes on every occurrence.

Exceptions, log errors, and agent failures

The Issues list has three filters: Exceptions, Logs, and All. It opens on Exceptions.

Exceptions covers anything Fixter could classify. That includes thrown exceptions with a stack trace, and also failures that never produce one:

• Agent and LLM failures. When a call to a model provider fails, or an agent stops early, or a tool it tried to run is missing, there is no stack trace to parse. Fixter recognises these by their shape rather than by their message text, so the same failure from different agent frameworks lands in one issue instead of scattering across hundreds. They carry the Agent runtime tag.
• Database and server errors reported in a log line rather than thrown, in the common Postgres and ClickHouse server formats.

Logs covers the remainder: ERROR-level log lines that carry no exception and no recognisable shape, grouped by their message text.

Issues you would never have reported

A service can be perfectly healthy and still be invisible, and nobody files a ticket about an absence. Fixter scans for two of them and raises each as an issue:

• Log severity never arrives. When more than 90 percent of a service’s logs land with no usable level, every ERROR it emits is indistinguishable from an INFO. Alert rules never match it, and the exception pipeline never sees it, so the service looks quiet because nothing can tell that it is not.
• Logs carry no trace context. When fewer than a quarter of a service’s logs carry a trace id, no failure can be followed across a request boundary. This one only fires for services that already send spans, so it never doubles up with “this service has no tracing at all”.

Both need a week of data and a service that has been seen on at least five days before they raise anything, so a service you wired up yesterday is left alone. The fix is usually a few lines in the logging setup: Telemetry covers what each signal needs, and /fixter:onboard runs the same check from your editor.

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 frame that threw and the frame that called it, so you know where to look before opening anything.
• Service and runtime. Runtime tags are JVM, Python, Node, .NET, Ruby, C++, Go, Postgres, Agent, and Log.
• 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, any error object that was captured alongside it, 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 3 days
Ongoing	Seen before that and still occurring
Regressed	Came back after at least 14 quiet days
Resolved	No longer counted as active

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

Nothing has to be closed by hand. An issue that nobody has seen for 15 days resolves itself, and reappears as Regressed if it comes back. You can also resolve one yourself, which is recorded as your decision rather than as a quiet timeout.

Every new issue is investigated

When Fixter detects an issue it has not seen before, it announces it and starts an investigation of it. An AI agent reads the stack trace, then queries the telemetry and the source around it, and writes its findings onto the issue. You can watch it work: the issue page shows the steps as they happen.

New issues start out going to email only, so a workspace with no Slack connected still hears about them and a workspace with Slack does not get its channel filled with the first week of findings. Point the issue tracking source at your Slack channels under Settings > Notifications when you want them there. See Alerts for how routing works, since it is the same mechanism for all three sources.

Only genuinely new issues are announced, so the backlog you already had does not arrive as a wall of messages. A burst of new ones collapses into a single card with a single investigation behind it rather than one message each, and the message leads with the service and the exception, so you can tell from the notification alone whether it is yours. Its View logs link lands on the event that triggered it.

The brief you get back carries:

Field	What it gives you
Root cause	One sentence naming what broke and what it costs
Mechanism	The chain from trigger to failure, with the source excerpt when the code was read
Evidence	What was found and where, cited from the stack, logs, traces, metrics, or code
Severity	Breaking (something fails), Degraded (slower or retried), or Noise (nothing affected)
Origin	Your code, a dependency, or infrastructure
Confidence	High, medium, or low
Suggested fix	What to change, when that is clear

Severity and origin are the two that save the most time on a full list: they separate the errors that are costing you something from the ones a handler already deals with, and they tell you whether the fix is even yours to make.

You can also run one on demand. The Investigate button on any issue starts a fresh investigation, and Re-investigate runs it again once you have changed something.

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 frames, the investigation’s root cause and evidence, 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.

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 error, get_log and get_log_neighbors for the raw record and what surrounded it, and run_sql for anything broader.

Working issues from your agent

Your agent can read the whole list without you opening the app. Ask it something like:

What issues are breaking in production right now, and which have a root cause already?

It calls list_issues, which filters by status, service, kind, or free text, and flags which issues already carry an investigation brief. get_issue then returns one issue in full, including that brief. Both are in the MCP tools reference.

Where issues fit

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

• Alerts. Fixter’s detectors alert on error bursts without any rule from you, and you can write rules of your own on the same signals.
• Investigations. The brief on an issue is the same capability that works your Slack alerts, pointed at an issue instead of a thread. See Investigations.

Related

• Telemetry: the logs and traces issues are built from
• Alerts: getting paged when errors spike
• Investigations: how the agent works a problem
• MCP tools: list_issues and get_issue