FeaturesIncidents

PR Autopsy

Automatically correlates each incident to the pull requests merged in the pre-incident window, scoring each PR's likelihood of being the root cause.

Overview

After a production incident, one of the first questions asked in every war room is: "which deploy caused this?" Finding the answer typically means cross-referencing deployment logs, Slack messages, and PR history — a manual process that can take 30 minutes to several hours depending on your team's tooling and deployment frequency.

Koalr's PR Autopsy eliminates that search. For every incident, it automatically identifies all pull requests merged into the affected service's repositories during a configurable pre-incident window and ranks each PR by its likelihood of being the culprit. The result is visible within seconds of the incident being created.

How the autopsy works

When an incident is created or synced from PagerDuty, OpsGenie, or incident.io, Koalr:

  1. Identifies the affected service from the incident's service field (or the service catalog mapping for your alert provider).
  2. Resolves the repositories mapped to that service in Koalr's service catalog.
  3. Looks back a configurable window (default: 2 hours) before the incident trigger time and collects all PRs merged to the default branch of those repositories within that window.
  4. For each PR found, retrieves the deploy risk score that was computed at the time of merge.
  5. Computes a culprit score for each PR (see below).
  6. Generates an AI root-cause hypothesis using the PR metadata and incident title.

The autopsy results appear on the incident detail page under the PR Autopsy tab.

Culprit score formula

Each PR in the autopsy window receives a culprit score from 0–100:

culprit_score = (risk_weight × deploy_risk_score)
              + (recency_weight × recency_factor)
              + (size_weight × change_size_factor)

Where the default weights are:

ComponentWeightDescription
Deploy risk score50%The PR's risk score at merge time (0–100). A PR that was already scored HIGH is a stronger candidate.
Recency factor30%How close to the incident trigger time the PR was merged. Merges in the final 15 minutes before the incident score 100; merges 2 hours prior score near 0. Computed as 1 - (minutes_before_incident / window_minutes).
Change size factor20%Normalized lines changed relative to other PRs in the window. Larger changes carry a higher base probability of introducing a defect.

The PR with the highest culprit score is highlighted as Most Likely Culprit in the UI. All other PRs in the window are displayed in the table sorted by culprit score descending.

If only one PR is in the correlation window, it is automatically highlighted as the most likely culprit regardless of score.

AI root-cause hypothesis

For incidents with at least one correlated PR, Koalr generates a plain-English root-cause hypothesis using Claude. The hypothesis is generated from:

  • The incident title and severity
  • The most likely culprit PR's title, description, and file-level change summary (not the full diff)
  • The PR's top-scoring risk signals at merge time (e.g., "schema migration detected", "author unfamiliar with changed files")
  • The PR author and reviewer names

Example output:

The most likely cause is the payments-service deployment at 14:32 UTC (PR #1847 — "Migrate checkout flow to new payment gateway"). This PR introduced schema changes to the transactions table and was merged without required CODEOWNERS approval from the @platform team. The deploy risk score was 84/100 at merge time, primarily driven by the DDL migration and low patch coverage (31%). The incident pattern — elevated 5xx errors on /checkout/complete — is consistent with a database schema mismatch during the migration window.

Important limitations:

  • The hypothesis is generated from PR metadata and risk signals, not from production logs, error traces, or runtime observability data. It is a probabilistic starting point for investigation, not a definitive root cause.
  • The AI does not have access to your application code. Its analysis is based on the PR title, description, file paths, and the structured risk signals Koalr already computed.
  • The hypothesis should always be validated against actual logs and traces before being included in a post-mortem.

Configuring the correlation window

The default correlation window is 2 hours. To adjust it:

  1. Go to Settings → Deployments.
  2. Under PR Autopsy, set the Correlation window value (in minutes).
  3. Click Save.

Supported range: 15 minutes to 24 hours. For organizations with very high deploy frequency (multiple deploys per hour), a shorter window reduces false positives. For organizations where deployments are batched or delayed after merge, a longer window may be needed to capture the actual deploy.

The correlation window applies to all new incidents from the time it is saved. It does not retroactively recompute autopsy results for existing incidents.

Example autopsy walkthrough

A P1 incident opens at 14:47 UTC for payments-service. Koalr resolves the service to the koalr-org/payments repository and looks back 2 hours to 12:47 UTC.

Three PRs are found in that window:

PRTitleMerged atRisk scoreCulprit score
#1847Migrate checkout to new payment gateway14:32 UTC8491
#1841Update logging format for audit trail13:15 UTC2218
#1839Bump @stripe/stripe-js to 3.2.112:52 UTC319

PR #1847 scores highest: it had the highest pre-existing risk score (84 — HIGH, driven by a schema migration), was merged only 15 minutes before the incident fired, and had the largest change size of the three. Koalr highlights it as Most Likely Culprit and generates a root-cause hypothesis describing the schema migration risk.

The on-call engineer opens PR #1847, confirms the migration was additive but includes a NOT NULL constraint added without a default — a known pattern for breaking running application instances during rolling deployment. The hypothesis was correct.

Automatic PR labeling on resolution

When an incident is resolved, Koalr automatically closes the loop on GitHub. If a causal PR was identified during the autopsy and was merged within the past 7 days, Koalr:

  1. Posts a comment on the GitHub PR summarizing the correlation — incident name, severity, hours between merge and incident fire, and a link to the full autopsy.
  2. Applies the label koalr:incident-correlated to the PR, making it permanently discoverable in GitHub search and your PR history.
  3. Records the link in Koalr's PR record so the correlation appears as a badge on the PR detail page.

This creates a durable audit trail directly in GitHub — no separate tool or dashboard needed to answer "which incidents have been linked to deployments?".

The label is created automatically in your repository the first time it is applied. No configuration is required.

Example comment:

## Incident Correlation — Koalr

This PR was merged **3h before** incident **DB connection timeout P1**
(Severity: P1, risk score: 84/100).

Koalr flagged this PR as the highest-risk deployment in the incident window.

[View full autopsy →](https://app.koalr.com/deploy-risk) | Powered by Koalr

Auto-labeling requires the GitHub integration and at least one incident integration (PagerDuty, OpsGenie, or incident.io). It triggers within 60 seconds of incident resolution.

Relationship to DORA MTTR

Mean Time to Restore (MTTR) is a core DORA metric. The primary driver of high MTTR is diagnosis time — the gap between "incident fires" and "root cause identified."

PR Autopsy directly compresses this gap. When engineers can open an incident and see the most likely culprit PR within seconds, they spend less time in the detection phase and more time in remediation. In practice, the largest MTTR improvements from PR Autopsy come in incidents where the culprit PR would otherwise have been missed due to low visibility (e.g., a dependency bump or a config change rather than a feature PR).

See DORA Metrics for how MTTR is benchmarked and trended in Koalr.

Requirements

  • At least one incident integration connected: PagerDuty, OpsGenie, or incident.io.
  • GitHub integration connected — PR data and deploy risk scores are sourced from GitHub.
  • Services mapped in the service catalog (Settings → Services). Without a service-to-repository mapping, Koalr cannot determine which repositories to search for correlated PRs.