Identifying the suspect PR with GitHub Compare

GitHub

Read the merged PR list in the compare view from oldest to newest.

Older first matters because deploys are typically batched. The first PR in the range is often the one that started flapping, with later PRs piling on top. Reading the timestamps gives a feel for whether the release was a single deploy or a series of merges.

Expected: You have a mental map of how many PRs are in the range and roughly when each landed.

GitHub

Filter mentally for PRs labelled 'migration', 'infra' or 'feature-flag'.

Migrations affect the database, infra changes touch deploys, networking or environment variables and feature flag flips change behaviour without a code path change. Any of these three deserves first inspection ahead of feature work or copy fixes. If the team uses other labels for risky changes (canary, rollout, schema) treat them the same.

Expected: You have a shortlist of 1 to 3 high-risk PRs from the compare view.

GitHub

Open each shortlisted PR in a new tab using ⌘ click on the PR title.

Keep the compare view open in the original tab. You will likely need to step back to it if the first suspect turns out to be unrelated. Working through the shortlist in tab order rather than chasing one PR deep avoids losing your place.

Expected: Each shortlisted PR is open in its own browser tab.

GitHub

On each suspect PR, click the 'Files changed' tab and skim the diff.

Look for changes to retry policies, timeout values, query patterns, environment variable defaults, feature flag flips and dependency upgrades. These are the patterns that most commonly cause sudden production regressions. Cosmetic changes, copy edits and test-only additions are almost never the cause.

Expected: You have read enough of each suspect to know roughly what it does.

GitHub

On each suspect PR, click the 'Checks' tab and inspect the deploy job history.

A green deploy result is necessary but not sufficient. Look at the deploy job history for retries. A deploy that succeeded on the second or third attempt often did not roll out cleanly to every instance, leaving the service in a mixed-version state. Mixed-version states cause exactly the kind of intermittent error spike that triggers a page.

Expected: You know whether each suspect's deploy ran cleanly or whether it retried.

GitHub

Pick the most likely suspect and capture the PR number, the merge commit SHA and the original author.

The merge commit SHA is needed for the rollback step. The author is needed because they are the right second reviewer on the eventual revert PR or the right person to consult on a hotfix forward. The PR number is the citation for the post-mortem.

Expected: You have the PR number, the merge commit SHA and the author name written down.