Pull Request Cycle Time Calculator

Introduction:

Review queues slow down delivery long before a release dashboard shows trouble. A pull request can look small, pass tests, and still sit for days because nobody picked it up, the author kept revising a draft, an approval waited on one person, or the final merge was postponed after review. Pull request cycle time turns that waiting into an elapsed-time measure that a team can compare across review windows.

In most engineering conversations, PR cycle time means the time from a chosen pull request start point to merge. The start point deserves care. Counting from creation includes draft time, early feedback, and author-side preparation. Counting from ready-for-review focuses the number on reviewer pickup and merge flow, but it can hide long draft periods if teams open draft PRs very early.

Averages are useful, but they are not enough for review work. One stale PR can disappear inside a busy month, and one emergency fix can make the average look healthier than the normal queue feels. Percentiles such as P85 and P95 show the slow tail, which is the older slice of completed PRs that usually causes context switching, stale approvals, merge conflicts, and repeated re-review.

PR cycle time is related to DORA change lead time, but the two measures answer different questions. Change lead time follows a change through production deployment. Pull request cycle time stops at merge, so it is better suited to reviewer routing, PR size, draft policy, and handoff habits inside the code review process.

Useful comparisons keep scope narrow. A single repository, service, or review lane usually produces a stronger signal than a mixed export containing unrelated teams, time zones, emergency fixes, generated-code changes, and abandoned old PRs. The number should start a review discussion, not replace one.

How to Use This Tool:

Use one reporting lane at a time, then set the timestamp rule before judging targets or charts. The summary updates from the pasted rows, and red or yellow messages should be fixed or carried into the interpretation.

1. Enter Repository or team so copied rows, downloaded tables, and JSON output can be traced back to the service or review lane being measured.
2. Choose Cycle start. Use Created when the full PR lifetime matters, or Ready for review when draft time should not count against the reviewer queue.
3. Set Cycle target and Review pickup target in hours. These values control target-miss labels, summary badges, and chart reference lines.
4. Paste rows into Pull request rows, browse for a CSV or TXT file, drop a file onto the textarea, or load the sample. Headered CSV can include pr, created_at, ready_at, first_review_at, approved_at, merged_at, status, and lines_changed. Three-column rows are read as PR, created time, and merge time.
5. Use Normalize after pasting uneven rows if you want a consistent header and timestamp layout. If the page shows Review PR input, add valid created_at and at least one usable merged_at. If it shows Data quality notes, check fallback starts, skipped rows, hidden parser notes, or timestamps that appear out of order.
6. Open Cycle Time Ledger first. Confirm each PR's Started, First review, Merged, Cycle time, Pickup wait, Target signal, and Review note.
7. Use Review Queue Brief, Cycle Target Chart, Review Stage Mix Chart, and JSON after the source rows and targets match the review window you plan to discuss.

Interpreting Results:

The headline number is average cycle time for merged PRs. Read it next to P85, target miss rate, and the open count. A low average with high P85 means the normal PR may move through review quickly while the slowest slice still needs active attention. A high open count means the completed sample may not match the queue reviewers are dealing with today.

Badge language is deliberately modest. Average on target means the mean completed cycle is within the selected cycle target. Tail on target means P85 is within that same target. Pickup aligned means median first-review wait is within the pickup target, or there is not enough first-review data to show a pickup delay.

A good cycle-time snapshot does not prove review quality, test strength, deployment readiness, or customer impact. Pair it with review comments, CI results, defect trends, and production delivery metrics before changing staffing rules or merge policy.

Technical Details:

Completed-cycle statistics use rows with a valid start timestamp and a merge timestamp at or after that start. Rows without a merge timestamp remain useful queue context, but they do not belong in average, median, P85, or P95 because their final duration is still unknown.

The chosen start rule changes the measurement basis. Created-to-merged includes draft time and early waiting. Ready-to-merged uses the ready timestamp when that value is present, then falls back to creation time for rows that do not include it. That fallback keeps the row visible while raising a data-quality note.

Formula Core:

Cycle duration is elapsed time from the selected start to merge, expressed in hours. Percentiles are computed from sorted completed-cycle values with interpolation between neighboring rows when the rank does not land on one exact row.

A row that starts at 09:00Z and merges at 18:30Z on the same day has a 9.5 hour cycle. If the cycle target is 24 hours, that row is inside target; if first review happened at 13:20Z, its pickup wait is 4.3 hours and can be judged against the pickup target separately.

Review-stage timing decomposes the same completed cycle. Pickup wait runs from start to the first review signal or approval. Review or approval time starts at that first review signal and ends at approval when approval exists inside the cycle, otherwise it can run to merge. Approval-to-merge time covers the final tail. Any completed-cycle time not explained by those timestamps is kept as unattributed time rather than guessed.

Fair comparisons need the same start rule, target hours, source columns, and reporting lane across runs. Mixing created-based and ready-based windows, or mixing repositories with different review policies, can make a real process change look like a measurement change.

Privacy and Accuracy Notes:

The calculator works in the browser from the pasted text or selected CSV/TXT file. That reduces unnecessary upload for sensitive repository data, but copied tables, downloaded files, screenshots, and shared page URLs can still disclose PR names, timestamps, and team context.

• Review rows before sharing exports, especially when PR titles, identifiers, or repository names reveal unreleased work.
• Use ISO-style timestamps with time zones when possible. Date-only or timezone-stripped exports can shift durations across workdays.
• Keep old abandoned PRs separate from normal reporting unless the goal is to quantify cleanup debt.

Worked Examples:

A checkout service export has four merged PRs with cycle times of 9.5, 12.0, 24.0, and 49.3 hours against a 24 hour Cycle target. Average cycle time is about 23.7 hours, but P85 is above target because the slowest PR stretches the tail. The useful follow-up is not the average alone; inspect the slow PR's Pickup wait, Review note, and stage mix.

A team that opens drafts early switches Cycle start to Ready for review. Three rows include ready_at, but one older export does not. That row still appears in Cycle Time Ledger using created time as the start, and Data quality notes records the fallback. Keep that caveat attached when comparing this run with a cleaner future export.

A review manager drops in a three-column CSV with PR, created time, and merge time. The page can calculate Cycle time, Average, and P85, but Pickup wait remains unavailable because no first-review or approval timestamp exists. The cycle-time number is still useful, but it cannot say whether delay came from reviewers or from the final merge step.

A troubleshooting case starts with a row whose merge timestamp is before the selected start. The row receives Invalid cycle and is excluded from completed-cycle statistics. Correct the timezone, timestamp order, or column mapping before using the average and percentile figures.

FAQ:

Glossary:

Cycle time

Elapsed time from the selected pull request start to merge.

Pickup wait

Elapsed time from the selected start to the first review signal or approval.

P85

The 85th percentile of completed-cycle hours, used to show slow-tail pressure.

Target miss rate

The share of merged pull requests whose cycle time exceeded the selected cycle target.

Unattributed time

Completed-cycle time not explained by pickup, review or approval, and approval-to-merge timestamps.

References:

• DORA's software delivery performance metrics, DORA.
• About pull request reviews, GitHub Docs.
• Merge request analytics, GitLab Docs.
• Pull request cycle time, Swarmia.