Issues
What groups events into an issue, regressions, assignment and comments.
An issue is what an error-severity log or an error-status span becomes once the same underlying problem has occurred enough times to matter. It is derived from your telemetry, not something you create by hand.
How events become one issue
A derivation cycle runs roughly once a minute. It masks the variable content out of each error's body or span name (UUIDs, numbers, timestamps, IP addresses), then hashes the masked form. Two errors that differ only in a UUID or a timestamp collapse into the same fingerprint; two errors that differ in the actual message stay separate issues. That masking behaviour is versioned: every issue records the fingerprint_version its hash was computed under, and a change to the mask list gets a new version rather than silently reinterpreting existing fingerprints.
The masked form is the issue's title, deliberately, so the grouping is legible. If ten different order IDs all produced the message order <uuid> failed to settle, that literal masked string, <uuid> and all, is what you see in the list. It is not a summary written after the fact.
An issue's culprit is the emitting service's name, not a per-signal field, because a service name is a stable catalog identifier that exists for spans and logs alike.
The persistence threshold
A single occurrence of an error is not yet an issue. Whether it becomes one depends on the issue policy in force for that service: its threshold_occurrences sets how many times the same fingerprint has to occur before it surfaces. Below the threshold, the occurrence is still recorded, just not shown in the issues list. Crossing the threshold creates the issue with the full count so far, not restarting at the threshold.
Two counts
Every issue carries two numbers, and they answer different questions. Total events is the running count since the issue was first seen, all time. In retention is how many of the underlying sampled events are still queryable, which shrinks once samples age past your retention window. The console labels both rather than showing a single number that quietly changes meaning after that boundary.
Lifecycle
An issue is unresolved, resolved, or ignored.
- Marking an issue resolved just records that. If the same fingerprint occurs again afterward, the issue regresses: it reopens automatically, at the same id, rather than creating a new issue. The regression is recorded with its own timestamp.
- Marking an issue ignored is different from resolved. An ignored issue does not regress: new occurrences still advance its count and last-seen time, but the status stays
ignoreduntil you change it by hand, and it does not return to the default list view or notify anyone. - The default list view excludes ignored issues; resolved issues stay visible by design.
Assignment
An issue can be assigned to a user or to a team, through one shared assignment mechanism. Assigning to someone who is not a member of the organization, or to a team in another organization, is refused with a specific message rather than silently accepted. If the assignee's account is later removed, or the team is deleted, the assignment is cleared rather than left pointing at something gone.
Comments and the work queue
The issues list is a work queue: filter by status, service, assignee or a free-text search term, sort by last seen or by total events, and triage with the keyboard (j/k to move, r/i/u to resolve, ignore or unresolve, a to assign). A bulk action applies to every issue matching the current filter, not only what is loaded on the current page, and the confirmation states the exact count before you commit.
Each issue carries a comment thread for handoff notes between teammates.
What a populated issues list looks like
Empty on this environment
The issues list below is empty on the local kind cluster used to write this
page. Deriving issues needs a background correlation worker that is
deliberately disabled on kind (no namespace quota to run it), so the
fingerprinting cycle never runs here even with error telemetry flowing in.
This is an environment limit, not the product's normal behaviour. See
docs/v2/testing/m06-issues.md for a full walk against a stack where the
worker runs, including screenshots of populated issues, regressions and
assignment.
That walk (org up0-test, 2026-09-02, 30 test cases) confirms the shape described above end to end: three identical errors became one issue at count 3; masking collapsed UUID, number, timestamp and IP variants into single issues while a genuinely different message stayed separate; a resolved issue reopened at the same id when the same error recurred; an ignored issue kept counting without reopening; and assignment, the filter language and keyboard triage all worked as documented.