Read-only PR review bottleneck brief for umami-software/umami

[xpinc17]

Hi Umami maintainers and community,

I put together a small read-only PR review bottleneck brief for umami-software/umami, based only on public GitHub PR data.

This is not meant as criticism or a request for action. I’m working on ApprovalOps, a tool for surfacing aging review work earlier, and I thought this snapshot might be useful as an outside maintenance-planning view.

Quick read

In this 90-day window, the main signal is first-review wait time. I did not observe post-approval idle over 48h, but 35 of 120 analyzed PRs waited more than 48h for a first review.

Window signal	Observed value
PRs analyzed	120
Waited >48h for first review	35
Total review-wait	340.3 PR-days
Median first-review wait	25.4h
Sat idle >48h after last approval	0

ApprovalOps would have surfaced an estimated 48% of observable review-wait time earlier, about 162.1 cumulative PR-days. This is a retrospective estimate from public data, not a guarantee.

Full read-only brief

PR Review Bottleneck Brief: umami-software/umami

Window: PRs created 2026-03-09 to 2026-06-07
Source: Public GitHub data only
Signal: Sufficient

Executive summary

Recent public PR activity shows a noticeable first-review wait pattern:

• 35 of 120 analyzed PRs waited more than 48h for a first review.
• The median first-review wait was 25.4h.
• No PRs in this window appeared to sit idle for more than 48h after their last approval.
• ApprovalOps is designed to surface aging review items earlier, before they slip out of view.

Where review time appears

Pattern	Observed count
New contributor in changed area	109
Quick reviewer alignment	64
Longer review cycles	33
Fast-track candidates	32
Review state changed after new commits	14

Longest observed first-review waits

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

• fix: redirect logged-in users from login page to dashboard #4099 - fix: redirect logged-in users from login page to dashboard - 52 days
• fix: increase website selector dropdown limit from 10 to 100 #4129 - fix: increase website selector dropdown limit from 10 to 100 - 43.8 days
• fix: make username login case-insensitive #4142 - fix: make username login case-insensitive - 36.9 days

Method and caveats

• This is a historical estimate from public GitHub data, not a live production measurement.
• Review-wait KPIs exclude open PRs from the baseline cohort and keep them only for in-flight diagnostics.
• Public-source analysis may not reflect branch protection, reviewer load, internal policy, or internal priority.
• The estimate treats codeowners-pending as an observability caveat when no other public-source risk signal remains.

If this kind of post is not appropriate for the repo discussions, feel free to remove it. Happy to share the methodology or regenerate the brief for a different time window if useful.