Total PR Cycle Time (Average)

Last updated: October 27, 2026

PR cycle time measures how long a merged pull request (PR) took from its first commit to its merge. Span shows it as "Time from First Commit to Merge".

Why it matters

Cycle time is the end-to-end speed of code delivery. Tracking it over time shows whether changes to review practices, PR size, or tooling are making delivery faster. The default Trimmed Average keeps one stale PR from dominating the trend.

How it works

Part

Definition

Start event: First Commit

The earliest author date among the PR's commits. Span leaves out merge commits, commits by ignored Git usernames, and commits it can't match to a known Git account. If the earliest commit is later than the moment the PR became ready for review, Span starts the clock at PR creation instead.

End event: Merged

When the PR merged into its target branch, from your Git platform.

Formula

Merged timestamp − First Commit timestamp. A negative result becomes 0.

Span measures elapsed clock time, including nights and evenings. It has no working-hours setting. If your organization excludes weekends, Span subtracts 24 hours for each Saturday and Sunday between the two dates, using your organization's time zone. Each PR lands on its merge date.

How the Trimmed Average is computed. Span caps each PR's cycle time at 30 days (2,592,000 seconds), then takes the mean:

FOR each merged PR:
  capped_cycle_time = MIN(actual_cycle_time, 30 days)

Trimmed Average = SUM(capped_cycle_times) / COUNT(PRs)

No PR is removed. A PR that took 45 days counts as 30. This is a capped mean, not a statistical trimmed mean that drops the top and bottom of the list.

Other aggregations. Pick one in Page settings:

Aggregation

Description

Trimmed Average (default)

Mean with each PR capped at 30 days

Median (P50)

Half of PRs are faster

75th Percentile (P75)

75% of PRs are at or below this value

90th Percentile (P90)

90% of PRs are at or below this value

Max

The longest PR cycle time in the period

Percentiles and Max use raw values with no cap. Each percentile returns the value of one real PR.

Stages. PR Lifecycle splits the same span into Coding (First Commit to PR Opened), Awaiting First Review (PR Opened to First Review), Reworking (First Review to Last Action), and Idling (Last Action to Merge). Span computes each stage as its own metric, so the stage values don't always add up to the total.

Setup

No setup is needed once a Git integration is connected. Find the metric in Insights → Productivity → Velocity → PR lifecycle, where the default range is First Commit to Merge, on team and person Metrics pages, and in custom dashboards.

A PR counts when all of these are true:

  • It merged. Open, closed-unmerged, and reverted PRs don't count.

  • Its author is a developer contributor, or a coding agent your organization set up as a dev agent.

  • Its repository, base branch, head branch, and author aren't on your ignore lists in Settings → Metrics.

PRs from Dependabot, Renovate, and other bot accounts don't count unless you map the account to a person or a dev agent.

Things to know

  • Worked example: a team has 10 merged PRs. Nine took 2 hours each and one took 60 days (1,440 hours). A plain average is (18 + 1,440) ÷ 10 = 145.8 hours. The Trimmed Average caps the long PR at 720 hours: (18 + 720) ÷ 10 = 73.8 hours. The Median is 2 hours. Use the Median to describe the typical PR and the Trimmed Average to see the effect of slow PRs.

  • Calendar time, not business hours: a PR opened Friday 17:00 and merged Monday 09:00 shows 64 hours with weekends included, and 16 hours with weekends excluded. Span never removes nights or holidays.

  • Why Span is longer than GitHub: GitHub shows PR creation to merge. Span starts at the first commit, so local work before the PR opened counts. To compare, select PR Opened to Merge on the PR Lifecycle slider.

  • Old commits stretch cycle time: Git keeps a commit's original author date through a rebase, amend, or cherry-pick. A cherry-picked commit written months ago moves First Commit back months. The Trimmed Average caps that PR at 30 days; the Median is barely affected.

  • Why a PR has no cycle time: check, in order: it hasn't merged; a later revert PR undid it; its author isn't a developer contributor; its repository or branch matches an ignore pattern; or none of its commits match a known Git account. With weekends excluded, a PR that started and finished inside one weekend also has no value.

  • Why a whole team is missing: usually team members whose Git accounts aren't linked to their Span profiles, or members not marked as developer contributors. Fix the account links or the contributor flag, and the PRs return on the next rebuild.

  • A PR counts in full where it merged: a PR that started last month and merged this week counts in this week at its full length. Span doesn't split a PR across periods.

  • Team history follows people: team views use today's team membership, so a person's PRs move with them when they change teams.

  • Past values can change: Span rebuilds cycle time from full history. Changing the weekend setting, ignore lists, or a contributor flag changes earlier periods.

Related articles

PR Lifecycle Metrics

PR Cycle Time Threshold Filter

How to setup weekend exclusion for metrics

How Span attributes metrics to teams

Need help?

Contact your Span account team or reach out to support@span.app.