PR Cycle Time report
The PR Cycle Time macro shows how long it takes for a pull request to go from opened to merged, and whether that time is improving. Data is fetched live from GitHub on each page load.
A long cycle time can signal review bottlenecks, large PRs, or scope creep.
Adding the macro to a page
Open a Confluence page in edit mode.
Type
/PR Cycle Timeor click + and search for PR Cycle Time (GitHub).The configuration panel opens on the right.
Set your options and click Save.
Configuration options
Option | Description |
|---|---|
Repositories (required) | Select one or more GitHub repositories. Type to search within your connected organisation. Up to 50 results shown; keep typing to narrow. |
Labels | Only include PRs with at least one of these labels. Leave empty for all PRs. |
Assignees | Only include PRs assigned to these users. Leave empty for everyone. |
Date range | Last 14 days, Last 30 days (default), or Last 90 days. |
Display | Full (KPI + chart) or Compact (KPI tile) for dashboards. |
Compare to previous period | Show whether the metric improved vs. the prior period. Enabled by default. |
Exclude bot / dependabot PRs | Filter out bot-authored PRs to avoid skewing the average. Enabled by default. |
Title (optional) | Custom heading. Defaults to PR Cycle Time - {selected repositories}. |
Metrics are computed from PRs the connected GitHub App can access. Repositories not included in the App's repository access will not appear in search results.
What is measured
Cycle time is calculated from the moment a PR is opened to the moment it is merged. Closed-without-merge PRs are excluded. The macro shows the average cycle time across all matching PRs in the selected period, a trend indicator, and a chart over time (Full display only).
Related pages
PR Throughput report - how many PRs your team is merging over time
Review Latency report - how long PRs wait before receiving their first review
Preparing sprint retrospectives - using the reporting macros alongside PR and issue data in retro pages
Updated: