JavaScript is turned off, so the numbers can’t open the pull requests behind them. The findings, method and code are also on GitHub: github.com/gurn3k/delivery-bottleneck-analyzer.

A Kubernetes pull request waits 4 days for review, then merges in under 2 hours

By Gurnek Khaira · Snapshot of 4 October 2026 · 1,027 merged and 1,270 open pull requests in kubernetes/kubernetes

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

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.
of the PRs waiting for review (231 of 368) belong to two teams, sig/api-machinery and sig/node. Kubernetes calls its teams SIGs, short for special interest groups.
open PRs, 21% of the backlog, have had no human response, for a median of 41 days.

Figure 1. Where a merged PR’s time goes

Days from ready for review, by stage

Source: GitHub API, 1,027 PRs merged 6 Jul to 3 October 2026. Each stage is measured from ready for review, so the stages overlap. Merge wait starts when both labels are set.

The largest queues

Each open PR sits in one team’s queue for one stage. Ranking queues by PR-days of waiting puts the ones with many PRs waiting a long time first. The unit is a team and a stage, never a person, because a long queue reflects capacity and process rather than anyone’s effort.

Table 1. Source: open PRs on 4 October 2026. PR-days of waiting = open PRs in the queue × their median wait. Queues under 10 PRs, on-hold PRs and PRs labeled with more than 3 SIGs are not ranked. Showing 10 of 31 ranked queues.
#	Team	Waiting on	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

Figure 2. Whose move the open PRs are waiting on

All 1,270 open PRs, each in exactly one state

No human response yetno comment or review from anyone but the author

median 41 d

Waiting for a reviewer’s lgtmsomeone responded; no lgtm yet

median 69 d

Waiting for an approverhas lgtm; not yet approved

median 26 d

Waiting to mergeboth labels set

Waiting on the authorrebase, requested changes or a process label

median 51 d

On holddraft, held or rotten

median 102 d

Source: GitHub API, open PRs on 4 October 2026. Waits run from the event that put each PR in its state. On-hold PRs are parked on purpose and never ranked.

The author’s move is 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.

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

By team

Every Kubernetes PR is labeled with the special interest groups (SIGs) that own it. The 10 teams with the most open PRs are shown first. Click any number for its PRs.

Table 2. Source: GitHub API, snapshot of 4 October 2026. A PR labeled with up to 3 SIGs counts toward each. — means fewer than 10 PRs, too few to report.
	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

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.

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.