Investigation
What changed, and what likely caused it, from real signals, never a guess
Every incident gets a real timeline, a deterministic best-guess at the likely cause with its own evidence and confidence score, and, once GitHub or GitLab is connected, the exact pull request and developer who shipped the change.
A timeline built from what actually happened
An incident's timeline is assembled from its own correlated signals, any job or dependency failure inside its window, and a handful of synthetic beats derived from data that already exists: the moment the incident opened, the first real customer impact (the earliest event in the window that actually carried an affected user), a human acknowledging it, and resolution. Every entry here is either a real signal/failure row or a real timestamp already on the incident; nothing is estimated or fabricated to fill a gap.
The incident show page and the postmortem document read from this exact same timeline, so the two can never silently disagree about what happened.
A rules engine that shows its own reasoning
Four rules are checked, in order, and the highest-confidence match wins: Deployment scores a deploy within 15 minutes before the incident, weighting timing 60% and, when release data exists on the spike's own events, how much of the spike actually referenced that release 40%. External dependency and Database each score proximity times magnitude of a latency spike, with a real corroborating failed call (or, for the database rule, a degraded/critical connection pool) adding a documented bonus on top, never inventing a precise multiplier where there isn't one. Background job scores on presence and volume alone (a floor of 20% confidence just for a real failure existing in the window, scaling up to full magnitude at 10 or more), since a failing job is often part of the spike itself, not a separate upstream cause with its own lead time to measure.
Every rule reports its own confidence percentage and a bulleted evidence list a human can check against, not an unexplained score; this is a small set of documented heuristics over real data, not statistical inference, AI, or an LLM call.
A real confidence score and evidence list, not an unexplained verdict.
Connect source control and a deploy names its own pull request
Once a project's GitHub or GitLab repository is connected, that provider's own deployment, push, and pull-request webhooks backfill the commit message, author, and PR number onto the matching deploy by commit SHA, automatically. The deployment rule's own explanation changes with it: instead of "v2.41.0 was deployed to production 5 minutes before this incident began," it reads "This incident appears related to PR #4821 by luke, deployed 5 minutes before the failure," with a direct link to the real pull request, right from the incident page.
A postmortem that never invents a fact
Generate a postmortem and it assembles a full markdown document, summary, root cause, timeline, customer impact, resolution, and recommended follow-ups, from the exact same real timeline and likely-cause result the incident page itself reads. Follow-up suggestions are templated per rule and name the real subject directly ("Add a canary or staged rollout before shipping changes like PR #4821 to all traffic at once"), never generic filler. Deliberately not an LLM call: every sentence traces back to a real fact already computed elsewhere, so it's instant, free, and can't claim something that didn't happen.
Written from the exact same timeline and likely cause the incident page already shows.