What it measures

Pull Request Throughput counts how many pull requests reach a merged state over a defined window, such as per day, per week, or per sprint. It treats the merged PR as the unit of delivered work, so it captures the rate at which discrete, reviewed changes land in the main branch.

It can be measured at the level of an individual, a team, a repository, or the whole organization. People often track it alongside the average size of those PRs, because a high count of tiny PRs and a low count of large PRs describe very different working styles.

How to measure it

Pull all merged pull requests from your git host such as GitHub, GitLab, or Bitbucket over the window you care about, then count them, grouped by author, team, or repo. The merge timestamp is the event that defines membership in the period, not the open date, so a PR opened last week and merged this week counts toward this week.

For a fuller picture, pair the raw count with PR size in lines or files changed, and exclude bot-generated and automated dependency PRs so they do not inflate the number. If you want a rate rather than a total, divide merged PRs by active contributor count or by elapsed time to compare teams of different sizes.

What it does not tell you

Pull Request Throughput tells you how many units of change merged. It tells you nothing about what those changes were for, whether they were worth doing, or whether they moved any goal forward. Ten merged PRs that refactor dead code, churn config, or rename variables score identically to ten PRs that shipped the feature a customer is waiting on. The metric is trivially gamed: split one change into five PRs and throughput rises while the actual work is unchanged.

It is also silent on quality and rework. A PR merged today that gets reverted or patched tomorrow still counts as throughput, so a number that is climbing can mask churn, instability, or a team shipping fast in the wrong direction.

This is the gap that Execution Intelligence is built to close: reading what is actually being built and why it matters, not just how many review units crossed the line. Throughput measures motion. It does not measure direction, value, or alignment to strategy.

How InteliG uses it

InteliG computes Pull Request Throughput directly from your real git and deployment history, with no manual instrumentation or tagging required. Because it reads the underlying commits and PRs, it does not stop at the count: Cognis connects each merged PR to the initiative the work belongs to, the contributors who did it, and the cost it consumed.

That connection turns a bare number into a verdict. Instead of reporting that throughput rose, InteliG can say which initiatives that volume actually advanced, which contributors carried it, and whether the spend behind it maps to declared strategy or to undirected motion.

Related terms

Lead Time for Changes — How long a change takes to go from first commit to running in production.
Cycle Time — The elapsed time from starting work on a change to delivering it.
Execution Intelligence — Reading how an organization actually executes by connecting code, people, strategy, and cost.