What this section is for
Delivery shows pull requests opened during the selected dates and how many have merged so far. Average time to merge runs from opening to merge for the merged requests in that set. This differs from DORA time from first commit to production. The page uses the same URL filters as the team overview.
When to use
- To find a repository or period where changes are taking longer to merge.
- Before changing the review process, to save the starting metrics.
- After a process change, to compare results and check other possible explanations for the difference.
Quick start
- 1Choose the dates, repository and optional author email.
- 2Read the note explaining that the cards count pull requests opened during the selected dates. Then compare opened and merged counts.
- 3Open the activity table for exact daily totals, including days with no events.
- 4Switch long periods to weekly grouping; boundary weeks can contain fewer than seven selected days.
Usage example
Scenario: The example on the homepage has four merged pull requests. Opening to merge took 8 and 26 hours in example/api, and 4 and 6 hours in example/web. The data is fictional.
- 1Without a filter, the mean is (8 + 26 + 4 + 6) / 4 = 11 hours.
- 2Select example/api: (8 + 26) / 2 = 17 hours. Select example/web: (4 + 6) / 2 = 5 hours.
- 3The 26 hours include waiting and overnight time. They are not working hours and do not explain the delay.
- 4For your own data, check opening and merge dates in GitHub, GitLab or Bitbucket. The average includes only merged pull requests opened during the selected period.
What this shows: The filter changes the average: 11 hours across both repositories, 17 for the API and 5 for the web app. Consider the number of changes and compare matching periods.
FAQ
How can I investigate a slow pull request?
Start with individual PRs with long merge times and inspect their history at the Git provider: review requests, responses, updates and CI results. Time from opening to merging includes waiting and non-working hours. It cannot by itself separate author effort from review waiting time or explain the delay.
Does this count every pull request merged during the selected dates?
No. The team overview and Delivery count merged requests from those opened during the selected dates. A request opened earlier is excluded even if it merged during this period.
What are Git activity windows?
They are periods when an author had Git events. Events for the same author on a UTC day are grouped if they are no more than 60 minutes apart. The window ends 15 minutes after the final event or at midnight, whichever comes first. Duplicate and overlapping events do not add time.
Are these working hours or task estimates?
No. Git activity windows miss work without Git events. They cannot exceed 24 hours per author per UTC day, although totals across authors can. Do not use them for payroll, task estimates or individual productivity.
Tips
- Read average merge time alongside the merged share: a few quickly merged changes do not tell you what happened to the rest.
- Record the date of a process change outside the chart if you plan to review its effect later.