PR Lifecycle Metrics

Last updated: February 17, 2026

The PR Lifecycle represents the stages of your development workflow. This article explains how each metric is calculated in Span, why it matters and what good looks like.

Available Display Options

Span provides five statistical aggregation methods for time-based metrics:

Display Name	What It Shows
Median (P50)	The middle value—50% of work is faster, 50% is slower
75th Percentile (P75)	The value where 75% of work is faster, 25% is slower
90th Percentile (P90)	The value where 90% of work is faster, 10% is slower
Trimmed Average	Average with extreme outliers capped to prevent distortion
Max	The absolute longest/highest value observed

Important: Not all metrics support all five options. Count metrics (like "Total PRs Merged") don't use aggregation—they show totals instead.

Coding

Definition

The time a developer spends actively coding and preparing a PR before opening it for review.

Start Event: First commit timestamp in the PR firstCommitAt
End Event: When PR is opened (non draft) readyForReviewAt

Calculation Details:

readyForReviewAt - firstCommitAt

• Measured in seconds, displayed in hours

• Respects organizational timezone settings

• Can exclude weekends based on org configuration

• Only includes merged PRs in aggregate metrics

• Filters to developer contributors only

Example Scenario:

• Developer commits initial code at 2:00 PM Monday

• PR marked ready for review at 4:30 PM Monday

• Coding time: 2.5 hours ✓

What does good look like?

The sweet spot is 1-4 hours for typical development work, but context matters.

P50 (Median)	~1 hour	Half of PRs opened within 1 hour of first commit
P75 (Target)	4-8 hours	Healthy range for most work
P90	~24 hours	Acceptable for complex features

Awaiting First Review

Definition

Time from PR opening until the first reviewer provides feedback. This is the #1 bottleneck for most engineering teams.

Start event: PR opened for Review readyForReviewAt
End Event: First review or comment received firstReviewedAt

Calculation Details:

firstReviewedAt - readyForReviewAt

Includes both formal reviews AND comments from non-author developers
First review = earliest of (review submission OR reviewer comment)
Measures actual human response time, not just approval events
Respects timezone and weekend exclusion settings

Example Scenario:

PR opened at 10:00 AM Monday
Reviewer provides feedback at 2:00 PM Monday
Awaiting First Review: 4 hours ✓

What does good look like?

P50	~4 Hours	Excellent; median review within half a day
P75	~48 Hours	Target; default working norm
P90	~120 Hours	Acceptable outlier; some PRs take longer accounting for weekends or complexity

PERFORMANCE LEVELS:

• World-Class: <24 hours P75

• Acceptable: 24-48 hours P75

• Problematic: >48 hours P75

• Critical: >72 hours P75

PRO TIP: This metric often represents 40-60% of total PR cycle time. Optimize this first for maximum impact.

Reworking

Definition

Reworking is a PR lifecycle stage that measures the time spent responding to reviews and making requested changes before the PR is ready to merge. It captures the active back-and-forth period between reviewers and the author.

Calculation Details:

This metric is calculated in time from First Review to Last Action.

Metric Name	`first_review_to_last_action`
Start Event	FirstReview — when the first review (approval, comment, or changes request) is submitted
End Event	LastAction — the last point of activity on the PR
Formula	`LastAction Timestamp - FirstReview Timestamp`

What is "Last Action"? The most recent of either:

Last commit pushed to the PR, OR
Last review/comment submitted on the PR

Important notes:

Excludes weekends (if configured)
Only bot reviews and author self-comments are excluded
Only exists for merged PRs

Example Scenarios:

Scenario 1: Single Review Cycle (1 hour 15 minutes)

10:00 AM - PR opened
10:15 AM - First review arrives requesting changes (START)
11:00 AM - Author pushes commit with fixes
11:30 AM - Reviewer approves (last action) (END)
Reworking Time: 1 hour 15 minutes

Scenario 2: Multiple Review Iterations (4 hours)

9:00 AM - First review with "changes requested" (START)
10:00 AM - Author commits fixes
11:00 AM - Second review with more comments
12:00 PM - Author commits again
1:00 PM - Reviewer approves (last action) (END)
Reworking Time: 4 hours

What does good look like?

< 2 hours	Excellent	Minimal back-and-forth, quick resolution of feedback
2-8 hours	Good	Reasonable time for author to respond and iterate within a workday
8-24 hours	Acceptable	Author needs time across work sessions or has complex changes
1-2 days	Concerning	Slow feedback loops or multiple review cycles
> 2 days	Poor	Significant bottleneck; unclear feedback or complex issues

Context Matters

Shorter Reworking times are typical for:

Bug fixes
Documentation updates
Small feature additions
Well-understood changes

Longer Reworking times are acceptable for:

Architectural changes
Large refactors
Security-sensitive code
Cross-team dependencies
Complex algorithm implementations

Idling

Definition

Idling measures the time period after the last action on a PR until it's merged. It captures how long a PR waits to be merged after all development and review activities have been completed.

Calculation Details:

Formula:

Idling Time = PR Merged Timestamp - Last Action Timestamp

Where Last Action = the most recent of:

Last commit on the PR, OR
Last review/comment on the PR

Implementation details:

Only non-bot reviewers' actions count
Self-comments from PR author excluded
Metric is NULL for unmerged PRs
Respects organization timezone and weekend exclusions
Stored as seconds, displayed as hours/days

Example Scenario:

Scenario: Delayed Merge After Approval

Tuesday 5:00 PM - Last review approved (last action)
Thursday 10:00 AM - PR merged
Idling Time: ~1.2 days

This indicates the PR sat idle for over a day after approval, potentially waiting for CI/CD, deployment windows, or manual merge action.

What does good look like?

What Good Looks Like

< 1 hour	Excellent	Immediate merge after completion
1-4 hours	Good	Merged same business day
4-24 hours	Acceptable	Next business day merge
> 24 hours	Concerning	Multiple days of unnecessary delay

Note: This metric has a "negative" connotation (flagged as "error" status) - lower values are always better.

High idling typically indicates:

Bottlenecks in merge/deployment processes
Waiting for CI/CD pipelines
Policy requirements (required approvals, checks)
Manual merge delays
Deployment scheduling constraints

The trimmed average for PR cycle time works by capping values at 30 days rather than using a traditional percentile-based trimmed mean. Here's how it works:

When you select "Average" (Trimmed Average):

Any PR with a cycle time exceeding 30 days is capped at exactly 30 days for the calculation
The average is then computed across all PRs using these capped values
PRs are NOT excluded - they stay in the dataset but their values are limited to the 30-day maximum

Example: If you have PRs with cycle times of: 2 days, 5 days, 35 days, 50 days

The calculation uses: 2 days, 5 days, 30 days, 30 days
Average = (2 + 5 + 30 + 30) / 4 = 16.75 days

Other Aggregation Options

When you select other aggregation types, no capping is applied:

P50 (Median) - uses raw values
P75 - uses raw values
P90 - uses raw values
Max - uses raw values

Key Differences from Traditional Trimmed Mean

This is NOT a standard statistical trimmed mean:

❌ Traditional trimmed mean: excludes top/bottom percentiles (e.g., remove top 10% and bottom 10%)
✅ Span's approach: caps outliers at a fixed threshold but keeps them in the calculation

Why This Approach?

The 30-day cap prevents extreme outliers (like PRs that stay open for months) from heavily skewing the average, while still accounting for their existence in your workflow.