Home Engineering Productivity Insights PR Cycle Time | Measure how fast code moves from first commit to merge

PR Cycle Time | Measure how fast code moves from first commit to merge

Last updated on Oct 29, 2025

The PR Cycle Time page gives teams a clear view of how long it takes code to move from first commit to merge. It’s the fastest way to identify where review bottlenecks occur and how efficiently work flows through GitHub.

Insights automatically calculates each stage — from when coding starts to when a pull request (PR) is merged — so you can understand your team’s delivery velocity and quality patterns.

Where to find it

Go to Velocity → PR Cycle Time in the left sidebar

How it works

Once you’ve connected GitHub (and optionally Jira), PR Cycle Time begins tracking all merged and open pull requests across repositories.

Each PR is broken into measurable stages:

  • Time to Open — time between the earliest commit in a branch and when the PR was opened.

  • In Review — duration between the PR opening and receiving the first review.

  • Time to Merge — time between PR open and PR merge.

  • Merged to Staging — optional filter to measure PRs merged into your selected staging branches only.

These metrics combine to calculate your average cycle time, shown in hours or days depending on the scope.

Filters and Controls

You can refine your data view using several filters:

Teams / Individuals Selector

Use this dropdown to toggle between organization, team, or individual views.

  • Teams tab: Aggregates data across all selected teams. Ideal for sprint retros or comparing backend vs frontend performance.

  • Individuals tab: Filters metrics to specific engineers for 1-on-1 review or performance insights.

  • Multi-select supported: Combine multiple users or teams in a single view.

💡 Pro Tip: Use the Teams view for management reviews, and Individuals to identify workload imbalances or top reviewers.

Repositories

The All Repositories dropdown narrows your metrics to one or more connected GitHub repositories.

  • Supports multi-selection for cross-repo tracking.

  • Each repo’s PRs, checks, and reviews are automatically merged into the same dataset.

  • Great for organizations running microservices or separate frontend/backend repos.

Date Range Picker

Controls which time window the metrics cover.

  • Choose quick presets like Last 7 Days, Last 14 Days, Last 30 Days, or Last 90 Days.

  • Use the calendar picker to set custom start and end dates.

  • All metrics — Time to Open, In Review, Time to Merge — recalculate dynamically for the selected period.

💡 Pro Tip: Use weekly ranges for sprint retros, and monthly or quarterly windows to track long-term team efficiency.

Branch / Staging Filter

The Branch time to merge policy modal defines which branches count as staging or deployment targets.
This directly powers the Merged to Staging metric on the PR Cycle Time dashboard.

Purpose:
Track how long it takes code to reach key environments (e.g., staging, release, production) across multiple repositories.

How it works:

  1. Click the ➕ icon beside Merged to Staging on the dashboard.

  2. The Branch time to merge policy modal opens.

  3. Under Label, name your policy (e.g., “Staging,” “Production,” or “Feature”).

  4. Under Select branch(es), pick one or more GitHub branches to include.

  5. Under Select Team(s), optionally scope this to specific teams.

  6. Click Save — your label becomes available as a selectable filter in PR Cycle Time.

Once configured, the Merged to Staging card shows cycle-time data only for PRs merged into those defined branches.

💡 Pro Tip: You can create multiple merge policies (for example, staging and main) to compare deployment speeds between environments.

AI Insight

Click AI Insight to open a contextual analysis sidebar powered by Optimal’s LLM agent.

  • Provides an auto-generated TL;DR summary of weekly or monthly trends.

  • Highlights week-over-week changes in Time to Open, In Review, and Time to Merge.

  • Surfaces activity trends, rework rates, PR sizes, and reviewer patterns automatically.

  • Ideal for leadership stand-ups and sprint retrospectives.

Search & Sorting Controls (Table View)

Below the main metric cards, the PR Table includes additional filtering and sorting tools:

  • Search Pull Requests — quickly locate a specific PR or issue ID.

  • Sort by columns: Reworks, Check Failure Rate, PR Size, or Comment Count.

  • Quick-highlight buttons:

    • Longest review time – helps spot slow or stuck PRs.

    • Most discussions – surfaces PRs with heavy reviewer activity.

    • Most check failures – flags builds needing attention.

Pro Tips

  • Use shorter date ranges (7–14 days) to monitor sprint performance.

  • Tag PRs consistently (feature, bugfix, refactor) to correlate cycle time by category in Distributions.

  • Combine with Allocations and Activity pages to spot bottlenecks between review and merge.

  • Check AI Insight weekly for auto-summarized team health reports.

Troubleshooting

  • Missing PRs? Ensure the repository is connected and synced.

  • No data for ‘Merged to Staging’? You may need to assign which branches count as staging in settings.

  • Unexpectedly low ‘In Review’ times? Automated reviews by Optibot are included; filter them out for human-only review times.

  • Check Failure Rate = 0%? Confirm CI checks are enabled in your GitHub workflow.