Read-only PR review bottleneck brief for payloadcms/payload

[xpinc17]

Hi Payload maintainers and community,

I’m building ApprovalOps, a tool for surfacing PR review bottlenecks earlier.

I ran a read-only public-source analysis of payloadcms/payload over a recent 90-day window, using only public GitHub data. There was no app installation, no private data access, and nothing was posted back to GitHub.

Quick read: most PRs appear to get an initial review within a few hours, but this 90-day window still shows a meaningful long tail: 119 PRs waited more than 48h, adding up to 762.6 cumulative PR-days of observed review-wait time.

Window signal	Observed value
PRs analyzed	702
Waited >48h for first review	119
Total review-wait	762.6 PR-days
Median first-review wait	5.7h
Post-approval idle >48h	11

I wanted to share the brief in case it is useful for repository maintenance planning. It is intentionally observational: the numbers are historical estimates from public data, not a judgment of the project or a claim that anything is “wrong”.

A few details that stood out:

• 119 of 702 analyzed PRs waited more than 48h for a first review.
• 11 approved PRs remained unmerged for more than 48h.
• The longest observed first-review waits were 52.5, 49.6, and 40.2 days.
• The largest recurring patterns were quick reviewer alignment, new contributors in changed areas, large changes, and fast-track candidates.

If this is useful, I’d be happy to share the methodology or run a different timeframe. If this kind of post is not appropriate for this Discussions category, I apologize and I’m happy to remove it.

PR Review Bottleneck Brief

PR Review Bottleneck Brief: payloadcms/payload

• Window: Created 2026-03-09 to 2026-06-07 (UTC, end-exclusive)
• Source: Public GitHub data (read-only, no app install)
• Signal: Sufficient
• Recommendation: This window shows observable review-wait friction worth a closer look. All figures are observed, not guaranteed.

What stood out

Most PRs appear to get an initial review within a few hours, but the window still shows a meaningful long tail of PRs waiting more than 48h for first review.

Metric	Value
PRs analyzed	702
Waited >48h for a first review	119
Total review-wait	762.6 PR-days
Median first-review wait	5.7h
Sat idle >48h after last approval	11

How ApprovalOps helps

In this historical window, ApprovalOps would have surfaced aging review items earlier: an estimated 38% of observable review-wait time, about 286.9 cumulative PR-days. This is a retrospective estimate, not a guarantee.

Where the wait appears

Signals can overlap across PRs; they explain recurring patterns and do not sum to the PR count.

Pattern	Count	What it means
Quick reviewer alignment	366	Reviewers converged quickly with consistent signals.
New contributor in changed area	289	The author had limited recent history in the touched code area, which can make reviewer assignment or confidence slower.
Large change	139	The PR is large in size or scope.
Fast-track candidates	87	Small or low-risk changes that may be safe to route through a lighter review path.
Longer review cycles	79	PRs with slower or back-and-forth review activity.

Longest observed first-review waits

Shown as longest observed waits in this window, not typical PRs.

PR	Observed wait
#16193 fix(graphql): virtual fields should be nullable in GraphQL schema (#16112)	52.5 days
#16304 test: clean up media documents after creation	49.6 days
#16348 fix: add type declarations for css export (TypeScript 6 compat)	40.2 days

Method & caveats

• Historical estimate only. This is not a live production measurement.
• Review wait time KPI excludes open PRs from the baseline cohort and keeps them only for in-flight diagnostics.
• Aggregate first-review wait metrics may use merge or close time as a fallback when a first-review timestamp is unavailable; the longest-wait examples only include PRs with observed first-review timestamps.
• Read-only public GitHub data may not reflect branch protection, reviewer load, or internal policy in a customer environment.
• Some PRs may have been waiting on CODEOWNERS review state that is only partially visible from public data.
• This read-only public GitHub analysis is observational and may differ from results in a fully installed production environment.