Investigating a problem

From a Problems row to an incident

Tapping a grouped entry in Problems opens its full incident detail: an identity you recognize (the same headline you tapped), then what the capture actually shows — status, when it was first observed, how long it's lasted, and whether it's recovered.

Status is a real state, not a guess

An incident that's still failing when you open it says so plainly, rather than guessing at an end time. Only once a later successful request to the same endpoint appears in the capture does the incident switch to Recovered, with the actual time that happened. Nothing here is inferred beyond what the capture actually contains.

Affected endpoints

The full list of hosts or endpoints involved, ordered by which one failed first — collapsed to a handful with a "show more" for incidents that touched a lot of surface area, so the count is visible at a glance without a screenful of scrolling first.

Confirmed and Possible findings

An incident is the network-wide event — many requests as evidence of one thing. Underneath that, individual findings about a specific request are split into two tiers: Confirmed findings are directly measured — a count, a byte delta, a status history, something the capture states outright. Possible findings are evidence-grounded but interpretive — a diagnosis built from the evidence rather than read straight off it. Both tiers show up together in Problems, but they're never presented as the same kind of claim.

From evidence to proof

When the capture contains an earlier successful request to the same endpoint, the incident offers Compare With Last Successful Request — a direct path into Compare, pre-loaded with the failure and its most recent working counterpart, so you're not hunting for the right two requests yourself.