An analysis of PR cycle time versus PR throughput data from 500+ DX customers (January-July 2026) finds that cycle time is not a reliable standalone predictor of throughput overall. Using quantile regression, the relationship is negligible for low-throughput organizations (25th percentile) but becomes progressively stronger and statistically significant at the median, 75th, and 90th percentiles. Around a 17-hour cycle time, median throughput begins to decline more sharply, suggesting this as a useful inflection point rather than a universal target. The takeaway is that high-throughput teams are most sensitive to cycle time slowdowns, while low-throughput teams likely face bottlenecks elsewhere, such as PR size, reviewer availability, or organizational context.

5m read timeFrom newsletter.getdx.com
Post cover image
Table of contents
Queuing theory behind cycle time and throughputCycle time matters more for high-throughput organizations than it does low-throughput organizations

Questions this post answers

Is there a statistical relationship between pull request cycle time and PR throughput?

Yes, but only for higher-throughput organizations. Quantile regression across 500+ engineering organizations found no significant relationship at the 25th percentile of throughput (p=0.366), a modest significant negative relationship at the median (p=0.0008, β=-4.0), and a much stronger negative relationship at the 75th and 90th percentiles (β=-11.7 and β=-12.8, both p<0.001). Teams debating whether to invest in faster reviews can weigh similar throughput data on daily.dev.

At what PR cycle time does throughput start to decline?

Median throughput begins to decline noticeably once PR cycle time exceeds around 17 hours. Below that mark, throughput stays fairly steady as cycle time increases, making 17 hours a useful inflection point rather than a hard productivity cutoff. Teams with cycle times past this threshold may benefit from examining review queues, reviewer availability, and PR size. Engineers tracking review bottlenecks can follow benchmarks like this cycle-time threshold on daily.dev.

Why doesn't reducing PR cycle time always increase throughput for a team?

For lower-throughput organizations, other factors like PR size, organizational context, and bottlenecks outside the review process play a bigger role, so cutting cycle time shows no statistically significant effect on throughput (p=0.366 at the 25th percentile). Cycle time only becomes a strong throughput driver once teams already operate at high throughput levels. Teams weighing which productivity metric to prioritize can compare findings like this on daily.dev.

17.1K Impressions