What it measures

Time to First Review captures the wait between a pull request becoming ready and a teammate engaging with it for the first time. The clock starts when the author marks the PR ready for review and stops at the first review action that is not the author's own: a comment, a requested change, or an approval.

It isolates one specific stage of delivery, the handoff from writing code to getting eyes on it. A short Time to First Review means work does not sit idle in the queue. A long one means finished code is waiting on people, not on the build.

How to measure it

Pull the PR open timestamp and the timestamp of the first non-author review event from your git host's API, then take the difference. Most teams report the median rather than the mean, since a few stale PRs left open over a weekend will drag the average and hide the typical experience.

Decide up front how you treat draft PRs, bot reviews, and self-comments, because those choices move the number more than the underlying behavior does. Start the clock at ready-for-review rather than at draft creation, and exclude automated checks so you are measuring human response, not CI latency. Segment by repository and by author to see whether the wait is uniform or concentrated on specific people or services.

What it does not tell you

Time to First Review tells you how fast someone responded, not whether the response was worth anything. A one-line 'looks good' that approves a flawed change scores identically to a careful review that catches a real defect. Fast first touch can coexist with shallow review, rubber-stamping, and rework that shows up later as reverts and incidents.

It also says nothing about what was being reviewed or why. A PR reviewed in ten minutes might advance a top-priority initiative or might be effort spent on work nobody asked for. The metric measures motion through the queue, not the direction or value of the code moving through it, and it cannot tell you whether the reviewed change is aligned with what the business actually needs.

This is the gap Execution Intelligence is built to close. Reading review latency tells you how quickly the team reacts; reading what is being built, which initiative it serves, and what it costs tells you whether that reaction is pointed at the right work. Speed at the wrong target is still the wrong target.

How InteliG uses it

InteliG computes Time to First Review directly from your real git and pull request history, with no manual instrumentation or tagging to maintain. It reconstructs the open-to-first-review interval from the actual events your team already produces.

Cognis then connects that latency to the initiative the pull request belongs to, the contributors involved on both sides of the review, and the cost of the work in flight. So a slow first review is not just a number on a chart: it is tied to a specific piece of strategy, the people it affects, and what the delay is costing, which is what turns review speed into a signal you can actually act on.

Related terms

Cycle Time — total elapsed time from first commit to merged or deployed change
Pull Request Throughput — how many pull requests a team merges in a given period
Execution Intelligence — reading what a team is actually building and why, connecting code to strategy and cost