Incidents: tracing back to what started it
Last updated:
What an incident tells you
The inbox lists facts. An incident tells the story: what opened, in which order, on which targets, and what most likely set it off.
Two questions come up whenever an alert fires:
- “Which one started?” A filling disk makes a container unhealthy, which fails a probe, which floods the logs with errors. Four alerts, one incident.
- “This crash — who is it hitting?” A crash almost never hits everyone: it concentrates on an OS version, a device model, an app release.
Three ways an incident is put together
| Type | What is grouped |
|---|---|
| Server cluster | Anomalies on the same machine, close in time, about the same service or container. |
| Crash bundle | Errors with similar symptoms that hit the same device population. |
| Across targets | A symptom in an application and an anomaly on the server it depends on, when the two overlap in time. |
The third case exists only if you declared the link between the two targets (“hosted on”, “depends on”). Without that link, the cockpit assumes nothing.
The timeline and the root
An incident opens on its timeline. The first line carries the Root badge: the oldest fact that nothing else in the cluster explains. The following ones state in plain words what they are a likely consequence of.
The confidence pill says what that naming is worth:
- Likely root — a single possible starting point;
- Plausible root — two candidates, timing decides;
- Needs a call — several possible starts; your judgement beats the calculation.
The evidence bundles
The table compares, for each notable value, its share in the incident against its share in a reference population, and spells the gap out in words (“six times more”).
That reference population is not the same everywhere, and the column says so:
- for an app release, it is the measured sessions — how many sessions actually ran on that release;
- for other dimensions (model, OS version), it is the crash distribution of the same target, with the observed issue excluded. That answers “does this crash hit Android 13 more than my app’s other crashes?”, not “what share of my install base runs Android 13?”.
A minimum count is required before any claim: two events on a rare device do not make a bundle.
Your three actions
- Confirm the root — you checked on the machine.
- Dismiss the root — the calculation got it wrong.
- Detach a fact — that link does not belong in this story.
These actions are kept. The recompute, which runs every twenty minutes, refreshes the evidence and never your verdict; a detached fact does not come back on its own.
“Roots only”
On the anomalies screen, the Roots only checkbox hides what an incident already explains as a consequence. A list of forty symptoms becomes three incidents. An anomaly no incident covers stays visible: the filter never hides what it does not understand.
From an alert
The View incident button on an inbox anomaly runs the search on demand and opens the matching incident. If nothing links that anomaly to other facts, the cockpit says so instead of opening an empty screen.