Issues

Issues describe recurring problems, errors, or system degradation that Firetiger has identified across your infrastructure. They’re the output of Firetiger’s triage pipeline — raw signals from Agent investigations get filtered, deduplicated, and organized into a structured view of what’s actually going wrong.

You can see your issues at /known-issues.

How issues get created

Issues aren’t created manually. When an Agent runs an investigation and discovers a problem, it reports what it found. A dedicated manager agent monitors these reports and decides what to do with each one:

If the problem matches an existing issue, the report is linked to it as a mention.
If the problem is new, the manager creates a new issue and assigns it an expert — a dedicated agent that owns that specific issue going forward.

This means that by the time something appears as an issue, it’s already been through a layer of LLM-driven triage. Duplicate reports get consolidated, and noise gets filtered out.

Issue status

Each issue has one of three statuses:

Active — the problem is ongoing and hasn’t been resolved.
Resolved — the problem has been verified as fixed. The expert agent requires evidence before marking an issue resolved, typically from a follow-up investigation confirming the errors or degradation have stopped.
Muted — the issue is acknowledged but deprioritized. Use this for known problems you’re choosing not to fix right now, or expected behavior that doesn’t need attention.

The issues list

The issues list at /known-issues shows all your issues, filterable by status. On the right side is a chat with the manager agent. This agent understands all your current issues and can help you reason about what’s happening across your systems.

Things you can ask the manager:

“What’s going on with the database right now?”
“Are any of these issues related to each other?”
“Create a new issue for the payment timeouts we’ve been seeing.”
“Should we merge these two issues?”

The manager can also kick off new investigations on your behalf if it needs more data to answer a question.

Issue details

Clicking into an issue shows its detail page. The key fields are:

Summary — a concise description of the problem, what’s known about it, and recommended actions. This is written for humans.
Mentions — links back to the individual investigation sessions that reported this problem. Each mention is a trail to when and how the issue was discovered. As new reports come in that match this issue, they’re added here automatically.
Links — external references like GitHub PRs, Linear tickets, Slack threads, or any other URL relevant to the issue.

The detail page also has a collapsible “Investigation Details” section. This is the expert agent’s internal working memory — it’s useful for understanding the agent’s reasoning, but it’s written in the agent’s own style rather than polished for human reading.

The expert agent

Each issue has its own expert agent, accessible via the chat panel on the right side of the detail page. The expert owns that specific issue and is responsible for driving it to resolution.

The expert works by delegating to investigation sessions linked to the issue. It can ask them to gather specific data, verify fixes, or check whether error patterns are still occurring. It maintains a structured memory of what’s been investigated and what’s been verified.

Things you can ask an expert:

“What’s the root cause?”
“Is this still happening? We deployed a fix at 2pm.”
“Who is affected by this?”
“Link this to our runbook.”
“Mark this as resolved.”

The expert will push back if you ask it to resolve an issue without evidence — it needs to see that the problem has actually stopped before it’ll close things out.

Notifications

By default, issues don’t notify anyone. To set up notifications, go to /known-issues/notifications.

The notifications page has a chat interface where you describe your notification policy conversationally. You tell it which connections should receive notifications — for example, a Slack connection — and which channels to use. The planner agent takes care of configuring the routing rules.

Without a notification policy, the only way to learn about issues is by checking the issues list directly.