Whose Move Is ItA Kubernetes pull request waits 4 days for review, then merges in under 2 hours
For 1 in 10, the review wait reaches about 7 weeks.
Software teams make changes through “pull requests” (PRs), proposals that a colleague must review and approve before they go in. This report looks at Kubernetes, one of the world’s largest open-source projects, and finds that changes spend almost all their time waiting to be reviewed and approved; once approved, they merge within hours. It shows which teams’ review queues hold the most waiting, and every number links to the real changes behind it, so anyone can check it.
Key findings
- 92% of the waiting happens before anyone approves a change. Getting a reviewer’s lgtm (“looks good to me”) took a median , and about 49 days or longer for the slowest 1 in 10. Once both review labels were set, merging took a median 1.7 hours. See Figure 1
- More than half of the open PRs are waiting on a reviewer. 694 of 1,270 open PRs (55%) wait on a reviewer or approver, and open PRs, 21% of the backlog, have had no human response, for a median of 41 days. See Figure 2
- Two review queues hold 30% of all the waiting. of the PRs waiting for review (231 of 368) belong to sig/api-machinery and sig/node. Kubernetes calls its teams SIGs, short for special interest groups. See Figure 3
- Two of 21 teams are on 59% of the open PRs. Of the 1,032 open PRs that aren’t on hold, are labeled for sig/api-machinery or sig/node. See Figure 4
Figure 1. Where a merged PR’s waiting goes
Every day from ready for review to merge, split by the stage it was spent in
92% of the waiting comes before a PR is approved. Merging takes the last 8%.
- 22% Waiting for a first responseno one but the author has commented
- 59% Responded, waiting for lgtma reviewer’s “looks good to me”
- 11% Has lgtm, waiting for approvalan approver signs off
- 8% Approved, waiting to mergetests and the merge bot
The same split for the 6 teams with the most merged PRs
Medians, p90 and how it’s measured
Per PR, each time below runs from ready for review, so they overlap. The slowest 10% take longer than the p90.
- The bar adds up waiting days across PRs, so a PR that waited 60 days counts six times as much as one that waited 10. The medians above give each PR one vote.
- If a label is removed and added again, the last add counts, so rework shows up as review time.
- Merge wait starts when both labels are set and covers tests and the merge bot.
2. More than half of the open PRs are waiting on a reviewer
Every open PR is waiting on someone: a reviewer, an approver, its own author, or no one because it’s parked. Each square below is one PR. Click a group to see its PRs.
Figure 2. Whose move it is, for every open PR
All 1,270 open PRs, one square each, grouped by who has to act next
695 · 55%Reviewers’ and approvers’ moveReviewers
337 · 27%The author’s moveAuthor
238 · 19%On hold, parked on purposeOn hold
- No human response yet , median 41 dno comment or review from anyone but the author
- Waiting for a reviewer’s lgtm , median 69 dsomeone responded; no lgtm yet
- Waiting for an approver , median 26 dhas lgtm; not yet approved
- Waiting to merge both labels set
- Waiting on the author , median 51 drebase, requested changes or a process label
- On hold , median 102 ddraft, held or rotten
How each state is decided
- Each open PR is in exactly one state, worked out from its labels and timeline on the snapshot date. Waits run from the event that put it there.
- Bots and the PR’s own author never count as a response.
- Labels are a proxy: a PR waiting on a reviewer who is away looks the same as one waiting because the change is hard.
- The 1 PR waiting to merge is counted with reviewers and approvers. On-hold PRs (draft, held or rotten) are parked on purpose and never ranked.
The author’s move is almost as common as the reviewer’s
337 open PRs are waiting on their author, against 368 waiting for a reviewer’s lgtm. Of the author’s queue, 175 need a rebase and only 21 have requested changes; the other 141 are waiting on a process label or the contributor licence check, most often a release note.
Approvals are not the constraint
Only 54 PRs have lgtm and are waiting for an approver, and 1 is waiting to merge.
3. Two review queues hold 30% of all the waiting
Each open PR sits in one team’s queue for one stage. Queues are ranked by PR-days of waiting, which counts both how many PRs wait and how long: 10 PRs waiting 10 days is 100 PR-days, the same as one PR waiting 100 days. The unit is a team and a stage, never a person, because a long queue reflects capacity and process rather than anyone’s effort.
Figure 3. The ten largest queues, drawn as PR-days
Each block’s width is its open PRs and its height is their median wait, so its area is the queue’s PR-days. Numbers match Table 1.
- Waiting for a reviewer’s lgtm
- No human response yet
- Waiting on the author
Width: open PRs in the queue. Height: their median wait.
| # | Team | Waiting on | Open PRs | Median wait | PR-days of waiting | Longest waiting |
|---|---|---|---|---|---|---|
| 1 | sig/api-machinery | Waiting for a reviewer’s lgtmnext move: reviewers | 85 d | 10,198 | #118378#128866#129087#133665#135287 | |
| 2 | sig/node | Waiting for a reviewer’s lgtmnext move: reviewers | 75 d | 9,032 | #128866#129854#133589#133665#134057 | |
| 3 | sig/api-machinery | No human response yetnext move: reviewers | 69 d | 6,473 | #136632#137551#137833#138061#138209 | |
| 4 | sig/testing | Waiting for a reviewer’s lgtmnext move: reviewers | 63 d | 4,736 | #126005#132167#129854#134163#136447 | |
| 5 | sig/node | Waiting on the authornext move: the PR’s author | 41 d | 4,591 | #134346#126052#137335#134076#139225 | |
| 6 | sig/api-machinery | Waiting on the authornext move: the PR’s author | 43 d | 3,778 | #126052#135537#135995#137477#137496 | |
| 7 | sig/scheduling | Waiting for a reviewer’s lgtmnext move: reviewers | 67 d | 2,492 | #132167#132761#134057#136217#139337 | |
| 8 | sig/node | No human response yetnext move: reviewers | 37 d | 2,436 | #138100#138380#138460#138721#138830 | |
| 9 | sig/apps | No human response yetnext move: reviewers | 41 d | 2,062 | #138209#138623#138681#139177#139307 | |
| 10 | sig/testing | Waiting on the authornext move: the PR’s author | 27 d | 1,637 | #136811#136974#137335#137477#137668 |
4. Two of 21 teams are on 59% of the open PRs
Kubernetes labels every PR with the teams that own it, which it calls special interest groups (SIGs). The waiting isn’t spread evenly: a few teams hold most of it. Click any number for its PRs.
Figure 4. Open PRs by team and stage
The stronger the blue, the more open PRs are waiting. Teams with 10 or more open PRs, largest first.
| Team open PRs | No response | Review (lgtm) | Approval | Author |
|---|---|---|---|---|
| sig/api-machinery391 | ||||
| sig/node381 | ||||
| sig/testing251 | ||||
| sig/apps141 | ||||
| sig/scheduling130 | ||||
| sig/storage89 | ||||
| sig/cli75 | 0 | |||
| sig/auth63 | ||||
| sig/instrumentation47 | ||||
| sig/network47 | ||||
| sig/windows20 | ||||
| sig/architecture19 | 0 | |||
| sig/etcd18 | 0 | |||
| sig/cloud-provider13 | 0 | |||
| sig/autoscaling12 | 0 |
Full table: every team, merged and open
The 10 teams with the most open PRs are shown first. Merged columns cover the last 90 days.
| Merged in 90 days | Open now | |||||||
|---|---|---|---|---|---|---|---|---|
| Team | PRs | Median ready to merged | p90 to lgtm | PRs | No response | Review | Approval | Author |
| sig/api-machinery | ||||||||
| sig/node | ||||||||
| sig/testing | ||||||||
| sig/apps | ||||||||
| sig/scheduling | ||||||||
| sig/storage | ||||||||
| sig/cli | 0 | |||||||
| sig/auth | ||||||||
| sig/instrumentation | ||||||||
| sig/network | ||||||||
| sig/windows | ||||||||
| sig/architecture | 0 | |||||||
| sig/etcd | 0 | |||||||
| sig/cloud-provider | 0 | |||||||
| sig/autoscaling | 0 | |||||||
| sig/cluster-lifecycle | 0 | |||||||
| sig/release | 0 | |||||||
| sig/scalability | 0 | — | — | 0 | ||||
| sig/contributor-experience | — | — | 0 | 0 | 0 | |||
| sig/docs | 0 | — | — | 0 | 0 | 0 | ||
| sig/security | — | — | 0 | 0 | 0 | 0 | 0 | |
| Reported separately, never ranked | ||||||||
| Cross-cutting (4+ SIGs) | ||||||||
| No SIG label | — | — | 0 | 0 | ||||
Risks brief
Written by openai/gpt-5-mini from this report’s numbers on 5 October 2026. Code checks that every bullet cites PRs and states only numbers that appear in the data, and rejects known misreadings. Reviewed by a person on 5 October 2026; 1 bullet reworded for clarity, 1 corrected.
- Merged PRs took a median 7.3 days from ready for review to merge; the slowest 10% took over 64 days.Cites #121910#129129#134037#133940#135486
- For merged PRs, reaching a reviewer lgtm took a median 4.1 days and 1 in 10 took about 49 days or longer; once both review labels were set the median merge time was 1.7 hours.Cites #121910#129129#133940#135486#135870
- Across the repo, 272 open PRs remain without any human response and have a median wait of 41 days in that queue.Cites #135011#133906#136632#137152#137551
- There are 368 open PRs waiting for a reviewer’s lgtm with a median wait of 69 days, and 231 of those 368 (63%) are labeled for sig/api-machinery or sig/node.Cites #118378#128866#129087#129854#133589
- By team queue, sig/api-machinery has 120 PRs waiting for a reviewer’s lgtm with a median wait of 85 days, making it the largest by total waiting in that stage.Cites #118378#128866#129087#133665#135287
Method and limits
How it was measured
- Timelines come straight from GitHub’s API for every PR merged in 90 days and every open PR.
- Review and approval are the lgtm and approved labels Kubernetes’ merge bot sets. If a label is removed and added again, the last add counts, so rework shows up as review time.
- Bots and the PR’s own author never count as a response.
- Only medians and p90 are shown. Groups under 10 PRs show — and are never ranked.
- Figure 1 is the one exception: it splits each merged PR’s wait into consecutive stages and adds the days up across PRs, so long waits count for more.
What it can’t show
- Labels are a proxy: a PR waiting on a reviewer who is away looks the same as one waiting because the change is hard.
- This is one snapshot, not a trend, and it doesn’t measure reviewer capacity.
- It names teams and stages, never people.
Checked against DevStats
Kubernetes’ own DevStats charts PR velocity over time. Recomputing its “time to approve and merge” definitions on this data, for PRs created in August and September 2026, gives the same picture: most of the time goes to waiting for lgtm, and merging after approval takes hours. The medians differ by 16 to 28%; the cross-check explains the likely causes.
How it was built
Built by Gurnek Khaira from a product spec, decision records and tickets. The build report covers tests, costs, the security review and what couldn’t be verified.