# Issues Deduplicated problems detected across your agent's traffic — technical failures, capability gaps, behavioral problems — each with a status (open/tracked/ignored/resolved) and a priority (critical/high/medium/low). The **Issues** page is the single place to triage what's going wrong with your agent. It groups similar problems — technical failures, requests the agent couldn't fulfil, repeated tool failures, behavioral gaps — into one row each, so you can see *what's broken and how often* without drowning in logs. ## What it is An **issue** is a deduplicated problem. Brizz detects individual occurrences across your traffic — one technical error, one request the agent couldn't fulfil, one anomalous tool latency — and groups the ones describing the same underlying problem into a single issue, tracking frequency, first/last seen, affected users, and the sessions behind it. Every issue carries an **issue type** — the taxonomy Brizz uses to describe what kind of problem it is: - **Missing Capability** — the user asked for something the agent cannot do yet. - **Missing Data** — the agent claims it lacks knowledge or data it should have been given. - **Broken Capability** — the capability exists and the tool was called, but it failed technically and the agent declared it couldn't finish. - **Technical Failure** — errors raised by the agent or its dependencies: error spans, HTTP 5xx, exceptions. - **Behavioral** — the agent answers, but the way it behaves doesn't serve the user. - **Performance** — latency and token-volume anomalies against the service's own baseline. - **Security/Safety** — abusive or out-of-policy interactions. - **Improvement** — an opportunity rather than a defect. ## How it's computed Two stages: 1. **Detection.** Analyzers run over your telemetry in different ways: **rule-based** checks cover technical errors (OpenTelemetry error status, HTTP 5xx, exception attributes, failed tool calls) and deprecated model usage; **statistical** checks flag token and latency anomalies against the service's own 30-day baseline; and **embedding or model-based** checks cover what needs reading the conversation — missing capabilities, repeated near-identical tool calls, abuse. 2. **Clustering.** New detections are routed by error type, matched against issues that already exist, and grouped into a new issue when nothing matches. A pass over the generated issue *titles* then merges duplicates, which is what keeps near-identical issues from fanning out. An issue's **mechanism** records which path produced it — `Automatic` for the clustering pipeline above, `Manual` for issues someone created by hand. It's available as a filter. ## How to read it in the dashboard The Issues page is filterable at the top: - **Status** — `Open`, `Tracked`, `Ignored`, `Resolved`. Adding any external link — a Jira, Linear, or Monday ticket, or a URL via **Add Link** — moves an issue to **Tracked**. It's a workflow state, not a live check: you can set it by hand, and removing the link doesn't move it back. `Open` and `Tracked` are the *active* statuses. Any status can move to any other, except `Open` while a Jira ticket is attached. - **Priority** — `Critical`, `High`, `Medium`, `Low`. What to work on first, derived from how serious the problem is and how much of your traffic it affects, recalculated over a rolling window. Set it by hand and Brizz stops recalculating it. - **Issue type** — the taxonomy above. Useful for routing: engineering takes Technical Failure and Broken Capability; product watches Missing Capability and Behavioral. - **Trend** — `Regressed` (reopened at some point in the last 7 days), `Escalating` (occurrence rate at least doubled in the last 24h versus the prior 7-day average), `New` (first seen under 7 days ago), `Ongoing` (everything else). They're evaluated in that order, so an escalating issue that's also new reads as Escalating. - **Assignee, external ticket, mechanism, labels** — plus **Tool**, which matches tools the issue's findings are about or were caused by. Journey, user, organization, satisfaction, and custom-property filters match issues by the sessions behind them. - **Skill** — if your agent is built out of named skills, narrows to issues whose sessions activated a given skill. It only offers values once Brizz has seen skill activity for the service. - **Search** — free-text match over issue titles and descriptions; title matches rank first. Click any row to open the detail panel. You'll see: - **Header** — title, issue type, priority, status, assignee, labels, and any linked external tickets. The title is editable on any issue; the description and issue type only on issues someone created by hand. - **Sessions** — a five-session preview of the evidence, linked for one-click drill-in. Narrow it to sessions with or without tickets, keep the Issues page's active session filters, or apply a value from **Breakdown**; **View all** opens the full issue-filtered list. - **Significance** — the affected share of all sessions, users, organizations, and relevant tool executions, followed by the same rate for each journey. The percentage is the raw rate; ordering and colour use a confidence-adjusted version, so a high rate over few sessions sorts lower and reads cooler. Tool executions stay neutral because calls within one session are not independent samples. - **Breakdown** — where the issue's sessions concentrate, by journey, intent, custom properties, and model. It leads with dimensions whose strongest value is at least twice as common (or at most half as common) as the service baseline, covers a meaningful share of the issue, and has enough evidence to clear the confidence check; quieter dimensions stay behind **Show more**. Open a value's menu to filter the evidence in place, open matching sessions with or without the issue filter, or copy the value. - **Activity** — the latest 200 status changes, priority overrides, assignments, and **Add Link** additions. Tickets created through the Jira, Linear, or Monday integrations are linked but not recorded here. ### Creating an issue by hand Spot a problem Brizz didn't flag and you can raise it from the message itself, so the evidence stays anchored to it. **Create issue** takes a title, description, type, priority (defaults to Medium), and optional assignee; **Attach to existing** adds the message to any active hand-created issue for the service, not only your own. Manual issues take every type except *Improvement* and behave like detected ones for status, assignment, and ticket links. The priority you set is never recalculated. :::info Manual issue creation is off by default. If you don't see the option on a message, [contact us](mailto:support@brizz.ai) to have it enabled — it isn't a setting an organization admin can change. ::: ### Issues overview The aggregate companion to the list — "how bad is it overall, and where is it concentrated?" - **Sessions with issues over time** — the share of sessions linked to a non-ignored issue. Recent buckets read low while clustering catches up, so don't call a drop a win too early. - **Issue hotspots** — highest-volume values on one dimension, shaded by count so a low-volume but serious row stands out next to a high-volume routine one. Click a named, non-empty cell to open that slice; **Other** and the unlabelled catch-all aren't clickable. - **Product-area map** — areas sized by open issues or affected sessions. The session sizing sums per-issue counts, so a session hit by several issues counts more than once. - **New vs resolved** — currently-Open against currently-Resolved issues. Tracked and Ignored are in neither series and each side is capped, so read it as a trend. ## How to act on it 1. **Triage by priority, not by recency.** A Critical from last week beats a Low from this morning. Watch the Escalating trend badge separately — a Medium that just doubled in rate is often the more urgent signal. 2. **Drill into one example before generalizing.** Open the linked session and read the actual conversation — the dashboard summary is only a hint. 3. **For Technical Failure and Broken Capability, look at the code or the call.** Common causes are missing error handling around provider calls or tool execution, or a tool failing on auth, timeouts, or 5xx. 4. **For Missing Capability, Missing Data, and Behavioral, look at the prompt, the data, or the agent design.** These often need a product decision about what the agent should be able to do rather than a stack-trace fix. 5. **Resolve aggressively.** Mark issues `Resolved` as soon as you ship a fix — Brizz reopens the issue if the problem comes back, and flags it as `Regressed` for a week after that. If you'd rather track the fix in your own tracker, create a Jira, Linear, or Monday ticket from the issue; that moves it to `Tracked` and links the two. ## See also - [Sessions](/docs/platform/sessions.md) — drill into the actual conversations contributing to an issue. - [User feedback](/docs/instrument/user-feedback.md) — map feedback events to power the session feedback badges, filters, and charts. Feedback is session context; it doesn't itself create issues. - [Events](/docs/platform/events.md) — browse the custom events you emit. Technical-error detection reads error spans and failed tool calls, not custom event payloads. - [Insights](/docs/platform/insights.md) — AI-generated reads that often point at the issues here. - [Labels](/docs/platform/labels.md) — the product-area and custom labels that organize issues. - [Issue trackers](/docs/integrations/issue-trackers.md) — push an issue to Jira, Linear, or Monday. - [AI assistant](/docs/platform/ai-assistant.md) — "Fix with your agent" starts from an issue.