Last quarter I kept a spreadsheet tracking one number for our platform team: the hours between a pull request being marked ready for review and the first human comment on it. Across six engineers spread from Lisbon to Seattle, the median was 31. Nothing was broken in any obvious way — CI was green, the diffs were small — yet every PR sat in a queue until someone in the right time zone woke up, cleared their standup, and found an uninterrupted hour.
That queue is the quiet tax on distributed engineering. Stack Overflow’s 2024 Developer Survey found that 92% of developers work remotely at least part of the time, which means the old model of tapping a teammate on the shoulder for a review has disappeared for most teams. What replaced it, in a lot of codebases, is an unmanaged review queue that nobody owns and nobody measures.
An async code review workflow fixes this by treating reviews the way on-call treats incidents: owned, measured, tiered by risk, and escalated automatically when they stall. In our stack, moving to this model cut median first-response time from 31 hours to 11 without adding a single meeting. Here is the exact setup, including the SLA we publish and the tooling that carries it.
Why Synchronous Review Breaks Across Time Zones
When a team shares an office, code review runs on ambient awareness. You see the PR land, you hear the author talk about it at lunch, and you review it in a gap between meetings. Distributed teams have none of that ambient layer, so every review depends on someone voluntarily noticing work that landed while they were asleep.
The failure pattern is predictable. A PR opens at 5 p.m. in Lisbon, the strongest reviewer is in Portland, and by the time Portland logs on, the author has already context-switched to something else. Each handoff adds hours, the diff grows stale in the author’s memory, and merge conflicts start compounding. What looks like a slow reviewer is usually a broken queue.
There is a human cost, too. In sync-heavy teams, review tends to pool on the same two senior people, who become single points of failure. Everyone else waits. Meanwhile junior engineers never build review judgment, because the feedback loop happens behind closed doors, in calls they were never part of.
The Four Rules of an Async Review Workflow
Before tooling, the ground rules. Our workflow runs on four commitments that fit in a paragraph:
- Every PR gets a named reviewer and a deadline the moment it opens. No orphaned pull requests, and no assuming that someone will pick it up.
- Feedback is written, specific, and backed by evidence. A recording, a benchmark, or a failing test — not a hallway summary that evaporated by the afternoon.
- Escalation is automatic, not social. A PR that breaches its SLA reassigns itself or pings a channel. Nobody has to awkwardly beg for review.
- The queue is public. Anyone can see what is waiting, how old it is, and who is holding it.
The fourth rule does more work than it sounds like it should. Once review wait time is visible on a dashboard, the team polices its own queue, and the conversation shifts from asking why one PR is stuck to understanding what is making the queue back up.
Set a Review SLA You Can Actually Hit
A service-level objective for code review sounds bureaucratic until you see what it replaces: every author guessing, every day, whether their PR is politely stuck or genuinely abandoned. Our SLA fits in one table:
| PR tier | First response | Review complete | Escalation |
|---|---|---|---|
| Low risk (docs, tests, copy) | 24 hours | 48 hours | Ping the team channel |
| Standard (features, refactors) | 8 working hours | 24 hours | Bot reassigns a second reviewer |
| High risk (auth, payments, migrations) | 4 working hours | 12 hours | Page the on-call reviewer |
| Hotfix / incident | 30 minutes | 2 hours | Merge, then mandatory post-review |
Two details make the SLA real rather than decorative. First, a first response means a substantive comment — a question, a concern, or an approval with reasoning. A bare LGTM does not stop the clock, because it gives the author nothing to act on. Second, we count the clock in working hours per reviewer region, so nobody fails an SLA because an author opened a PR at 6 p.m. on their Friday.
Tier Every PR by Risk
Review capacity is finite, so the workflow spends it deliberately. Every PR gets a tier label the moment it opens:
- Low risk — documentation, test-only changes, copy edits. Any team member can review, and the SLA is generous.
- Standard — feature work and refactors with covered test paths. Routed through CODEOWNERS to the owning team.
- High risk — authentication, payment flows, schema migrations, anything touching PII. Requires a reviewer with domain depth, and the walkthrough recording is mandatory, not optional.
Pair the tiers with a short self-check that junior engineers run before requesting review: does the PR description explain the why, are the tests meaningful rather than decorative, and is the diff under roughly 400 lines? Most review delay is really a readability problem in disguise, and the self-check catches it before a reviewer has to.
The 400-line figure is not dogma; it is a forcing function. In our repo, changes that cross it almost always contain two separable ideas, and splitting them means each review is faster, each rollback is cheaper, and each revert is safer. When a large diff genuinely cannot be split — a migration script, a rename across packages — say so in the description and request a two-pass review: design first, implementation second.
Tools That Carry the Workflow
You can run this on almost any modern stack. What matters is that the tool can route reviews automatically, expose the queue, and make wait time measurable. Four that we use or have used:
| Tool | Best for | Strengths | Trade-offs |
|---|---|---|---|
| GitHub (CODEOWNERS + merge queue) | Teams staying on one platform | Auto-assigns reviewers, enforces required reviews, queue visible in PR views | SLA timers need a bot or an Action; stacked PRs get awkward |
| GitLab (approval rules) | Teams that want rules baked in | Per-path approval rules, merge trains, solid wait-time reporting out of the box | Approval rules take real tuning; UI pace lags GitHub for some teams |
| Graphite | Stacked-PR workflows | Makes small, reviewable stacks painless; fast keyboard-first review UI | Merger is a paid feature; the team needs buy-in on the stacking habit |
| Loom | Recorded walkthroughs | Two-minute context videos attached to PRs kill most quick-sync calls | Videos rot; pair them with written diffs, never replace them |
Do not overthink the platform choice. The workflow depends on three capabilities — automatic assignment, a visible queue, and measurable wait time — and every tool above provides them in some form. We ran GitHub with a small review-bot Action for a year before adopting Graphite, and the workflow held up in both configurations. Pick the tool your team already opens every morning, wire the SLA into it, and resist the urge to migrate platforms before you have measured anything.
A Review SLA Template You Can Copy
Here is the full policy text from our handbook. Steal it and adjust the numbers:
Review SLA v1.0
- Every PR names at least one reviewer and a tier at open time.
- First substantive response: 8 working hours for standard, 4 for high risk, 24 for low risk.
- Review complete: 24 working hours for standard, 12 for high risk, 48 for low risk.
- A bare LGTM does not count as a first response.
- Breaches reassign to the fallback reviewer automatically and notify the team channel.
- Median and 90th percentile wait times are reviewed at the monthly engineering retro.
The template matters less than the habit of publishing it. A review SLA nobody can find is a suggestion; one that lives in the handbook next to your on-call rotation is a commitment.
Common Failure Modes
Three ways this workflow goes wrong in practice.
The SLA exists only in the wiki. If breaches do not reassign anything, the SLA decays into decoration within a month. Wire the escalation first, publish the policy second.
Review theatre. Written async feedback can drift into nitpick density contests — thirty comments on variable naming, none on the data model. The tier definitions help here: high-risk PRs require a review of the design, not the punctuation.
Recording fatigue. Walkthrough videos are powerful for architectural changes and useless as a blanket mandate. We require them for the high-risk tier only; for standard PRs, a good written description wins.
Wrap-up
An async code review workflow is not a tool purchase. It is four rules, one table, and the discipline to measure what used to be invisible: name a reviewer at open time, publish response targets per risk tier, record context for the changes that deserve it, and let the queue police itself.
Start smaller than you think. Instrument wait time for two weeks, publish the SLA table above, and let the data argue for the rest. The first month will feel mechanical. The month after, PRs stop dying quietly in queues, and your senior engineers stop being the bottleneck everyone silently routes around.