---
title: "Incidents: tracing back to what started it"
description: "The cockpit links facts together — anomalies from one incident, crashes hitting the same population, an app symptom explained by its server — and names the likely root."
lang: en
canonical: "https://www.stathall.com/en/docs/incidents/"
updated: "2026-09-22"
---

# Incidents: tracing back to what started it


## 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.