The number telling you your code is being reviewed may be counting a machine. It improves as your reviewers fall further behind, which is the opposite of what you need it to do.
No code, no titles, no branch names.
The problem
If your test function is smaller than it was and you still own what goes out to production, code review might be the last place a person sees the work before it ships. It is also the part of the process most likely to have a metric on a dashboard, looking healthy.
That metric now has a machine in it. On Tailwind CSS the median time to first review is six minutes. The median time to the first review a person submitted is just over a day, on the same pull requests over the same eight weeks.
Four of the seven repositories I reviewed for this report got a first review inside half an hour. On three of them, hours or a full day passed before a person looked at the work.
What it lets you check
- Know when a fast first review still tells you something, and when it does not
- See what a review bot does to both numbers, from the eight weeks either side of one arriving
- Work out how much of your own review count is tooling
- Separate the work your tooling reports as unreviewed from the work nobody read
- Find out how few people do the human review, and what that means when one of them is away
Seven pages.
Who it’s for
Engineering leaders who own what gets released into production. More code arrives every week and fewer people are left to read it, and the ones who still do are going line by line until they cannot any more. Some of it is shipping with nobody having read it at all, and the dashboard will not tell you which.
The small print
Metadata only: numbers, usernames, states and timestamps. No branch names either.
Merged pull requests from each repository, 08.07.2026 to 02.09.2026, capped at the 300 most recent merges. Reviews people submitted on their own pull requests were excluded from every figure. Nobody is named.