Probable Cause
A deterministic guess at what actually caused it, never a black box
Four named rules, deployment, external dependency, database, and background job, each scored from real signals already on the incident, and, once GitHub or GitLab is connected, the exact pull request and developer who shipped the change.
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.
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.