If you manage engineering teams in GitHub, the most useful way to measure PR cycle time is to break it down by team, compare the same window over time, and look at the parts of the PR flow that changed. That gives you a clearer read on whether cycle time moved because of review, queueing, rework, or handoff patterns.
For a practical baseline, track a team-level median cycle time, a trend over time, and a few supporting slices such as PR size, review responsiveness, and reopened or stalled PRs. Then compare one reporting window to the next so you can describe the shift in context instead of treating a single number as the story.
What PR cycle time means for an engineering team
PR cycle time is the time from pull request open to merge. At team level, it helps answer a simple question: how long does it typically take this team to move a change through review and into the codebase?
For managers, the value is not just the average. It is the spread, the trend, and the parts of the workflow that slow down specific teams. A team with stable cycle time but growing variance may need different attention than a team whose median is rising steadily.
When you measure it in GitHub, keep the scope consistent. Use a defined team-to-repo mapping so the metric reflects the work you want to manage, and review the definition before comparing one team with another. See teams and repos for scoping guidance and metrics for the core definitions.
The core metrics to track by team
Start with a small set of metrics that explain the flow, not just the outcome.
- Median PR cycle time for the team
- Trend line across weekly or daily windows
- PR count in the same period, to avoid reading a tiny sample as a pattern
- Review response time, especially if cycle time moved up
- Time to merge after first review, which often shows review bottlenecks
- Reopened or long-lived PRs, which can widen the tail
If you only report one number, managers often miss why it changed. A team dashboard works better when it pairs the headline metric with supporting context. The overview dashboard and team analytics views are designed for that kind of reading; see dashboard and team analytics.
How to compare two reporting windows
To understand change, compare the current window with the prior one on the same cadence. Weekly comparisons are usually easier for staff meetings, while monthly comparisons are better for broader planning.
Look for three things:
- Direction: did cycle time go up, down, or stay flat?
- Shape: did the whole distribution shift, or only the long tail?
- Mix: did PR size, volume, or team allocation change between windows?
Example: if median PR cycle time is flat but the upper end is longer, the team may have a small number of stuck PRs rather than a general slowdown. If the median rose and review response time rose with it, review queueing is a likely place to inspect.
That is why a window-over-window read is more useful than a single snapshot. For historical comparison and point-in-time reporting, pair trend charts with saved snapshots; see snapshots.
Break cycle time into parts you can act on
Cycle time by itself tells you that something changed. The supporting breakdown tells you where to look.
Review responsiveness
If the time to first review or time between review rounds grows, the team may be waiting on reviewers, losing context between comment rounds, or splitting attention across too many PRs. For a deeper read, use code review responsiveness.
PR size and complexity
Larger PRs often take longer to review and merge. If the team’s cycle time moved up alongside PR size, the issue may be work batching rather than review delay.
Stalled or reopened PRs
Long-lived PRs and reopen events often widen the tail even when the median looks fine. Watch whether these are concentrated in one repo, one team, or one kind of change.
Scoped ownership
If you map teams to repos, you can separate team behavior from repository-specific friction. That matters when teams share codebases or work across multiple services. See teams and repos.
What to show in a team-level dashboard
Managers usually need a compact view they can scan before a staff meeting and then drill into when something shifts.
- A team performance table with current cycle time and change versus the prior window
- A trend chart that shows whether the line is stable, improving, or drifting
- A chart grid that lets you drill into the specific factors behind the change
- Milestone markers for notable shifts, such as a release cutover or process change
- A weekly summary that highlights where attention is needed
When these views are aligned, you can move from "cycle time went up" to "it moved up because review wait time grew and two long-lived PRs sat in queue." That is a much better conversation for engineering leads.
If you run weekly staff meetings, pair the metric with an attention callout so the discussion stays focused. See weekly summary and staff meeting metrics. If you want a structured walkthrough, the product tour is a good place to start.
How to keep the metric trustworthy
PR cycle time is only useful when the definition stays consistent.
- Use the same team/repo scope across windows
- Keep the reporting cadence consistent
- Check whether merges, rebases, or unusual PR workflows affect the count
- Review whether very small samples are being overread
- Document known limitations before presenting the metric broadly
If you are still deciding which delivery metrics to standardize, start with one team, one cadence, and one comparison rule. Then expand once the team understands the reading model. For setup and known constraints, see setup and limitations. If you need a broader framing, choosing delivery metrics is a useful companion.
FAQ
Should I use average or median PR cycle time?
Use median for team reporting because it is less distorted by a few unusually long PRs. Keep the tail visible so the median does not hide stuck work.
How often should I review PR cycle time by team?
Weekly works well for manager check-ins and staff meetings. Monthly is better for longer planning cycles, but it can hide short-term shifts in review load or queueing.
What if one team has much higher cycle time than others?
First verify that the teams are scoped the same way. Then compare PR size, review responsiveness, and long-lived PRs before assuming the team itself is the problem.
Can I use cycle time alone to judge delivery performance?
No. It is a strong indicator, but it should be read alongside PR volume, review responsiveness, and the distribution of PR age. One number rarely explains the full picture.
How do I explain a change between two windows?
State the direction, the size of the shift, and the likely contributing parts of the flow. For example: "Median cycle time rose from one window to the next, mainly because review response time increased and the long tail widened."
If you want to see team-level PR cycle time in a clean, scannable workflow, you can start a read-only connection and review your first team view at /app/onboarding.