LinearB Metrics Glossary

Time from when coding begins on a branch to when the work is released.
Cycle Time is composed of four measurable sub-phases: Coding Time, Pickup Time, Review Time, and Deploy Time.

The average duration of the four sub-phases across all completed branches within the selected time range or iteration.

Cycle Time is a core measure of delivery speed. It reflects your team’s ability to deliver software efficiently end-to-end. Understanding where time accumulates helps you identify bottlenecks, drive process improvements, and improve overall flow efficiency.

Based on the 2026 LinearB Software Engineering Benchmarks Report (8.1M+ PRs across 4,800 organizations, calculated at the 75th percentile/P75):

2026 Benchmarks (hours, P75)
Elite: < 25 hours
Good: 25 – 72 hours
Fair: 73 – 161 hours
Needs focus: > 161 hours

See LinearB's full 2026 Benchmarks Report .

Use these ranges as a reference point when comparing your team’s Cycle Time. If your workspace uses a different aggregation method (Average, Median, P75, P90), focus on direction of change over time as well as how you compare to these bands.

Time developers spend actively coding before a pull request is opened.

From the first commit on a branch until the PR is created:

Coding Time = pr_created_at − first_commit_timestamp

Draft or WIP pull requests are excluded from Cycle Time and their duration is counted as Coding Time instead.

For configuration details, see Draft Pull Requests .

Coding Time indicates how long work stays in progress before review. Prolonged Coding Time can hide risk (large, unreviewed changes) and make it harder to spot misaligned or blocked work early.

An Admin user can choose how Coding Time begins:

• By first commit (default)
• By issue state moving to In Progress

Configuration path: Settings → Advanced (Coding Time configuration near the bottom).

Time between when a PR is opened (or moved from draft to active) and the first non-author review activity.

From PR creation to the first reviewer comment or review:

Pickup Time = first_comment_at − pr_created_at

• If a PR is approved or merged without comments, Pickup Time is measured from PR open time to the first approval or merge timestamp.
• Comments from the PR author do not count as review and are ignored for this transition.

Pickup Time captures reviewer responsiveness and prioritization. Long Pickup Time often indicates review bottlenecks, unclear ownership, or overloaded reviewers.

Time from the start of review to when a PR is merged.

From the first non-author review activity until the PR is merged:

Review Time = pr_merged_at − first_comment_at

• Comments or reviews from the PR author (self-reviews) are ignored when determining the review start.
• If a PR is approved or merged without any review activity, LinearB records Review Time as 0 for that PR.

Review Time reflects how smoothly code review is happening. Long Review Time can signal unclear ownership, overloaded reviewers, or process friction.

Time from when a PR is merged until it is released to production.

From merge to production release:

Deploy Time = released_at − pr_merged_at

Deploy Time shows how long it takes to move merged work into the hands of users. Long Deploy Time can indicate manual release processes, complex approvals, or slow CI/CD.

An Admin user can configure how LinearB detects releases under: Settings → Advanced → Release Detection. Supported methods include:

• Using Git tags on a release branch.
• Pull requests into a dedicated release branch (e.g., main, master).
• Direct merges into a dedicated release branch.
• API Integration (Deployment API).

Time from the start of review to the first approval.

From first reviewer comment/review to first approval:

Time to Approve = first_approval_at − first_reviewer_comment_or_review_at

• PRs approved without any prior comments or explicit reviews are treated as having Time to Approve of 0.

Time to Approve highlights how quickly reviewers make a decision once they start engaging with the PR. Long Time to Approve can point to unclear standards, over-scoped PRs, or misaligned expectations.

Time from first approval until the PR is merged.

From first approval to merge:

Time to Merge = pr_merged_at − first_approval_at

Time to Merge highlights friction after approval—such as waiting for CI, additional approvals, or release coordination. Large gaps here can hide delays that aren’t visible in review throughput alone.

The final difference between the head branch and the base branch when the pull request is created. It reflects the net change in code after all modifications have been applied.

Final diff at PR creation:

PR Size = additions + deletions + modifications

Smaller PRs are easier and safer to review. Large PRs tend to increase review time, reduce review quality, and raise the risk of defects in production.

The average number of comments made during review. This includes general comments, suggestions, or requests for changes.

Average comments per PR over the selected period.

Review Depth reflects how thorough reviews are. Too low can indicate rubber-stamping; too high may signal overly large or unclear PRs.

The number of PRs merged with no review activity.

Count of merged PRs where the review count is 0 during the selected period.

High “no review” merges can reveal bypassed controls and correlate with production issues or defects.

The percentage of changed lines that are net new code (as opposed to modifications of existing lines).

New Code Ratio = new_lines_added ÷ total_lines_changed

Indicates the balance between creating new functionality vs. modifying existing code. Useful for understanding how much of the team’s effort is focused on net new value.

The ratio of legacy code (for example, older than a configured age threshold) that was modified in the selected period.

Refactor Ratio = legacy_code_lines_changed ÷ total_lines_changed

Shows investment in maintainability and technical debt reduction. Higher refactor activity can be healthy when aligned with strategy.

The ratio of recently-changed code (for example, changed within a recent time window) that is modified again in the selected period.

Rework Ratio = recent_code_lines_changed ÷ total_lines_changed

High rework can signal churn or instability in new work. It is a quality-risk signal that can indicate unclear requirements or rushed changes.

A measure of how much a PR changes after it is first opened, indicating how “ready” it was at submission time.

LinearB compares the state of the branch at two points:

• At PR creation – the initial state of the branch.
• At PR closure – the final state after all changes.

The ratio reflects the extent of changes made after initial submission (for example, additional commits to address feedback, fixes, or rework).

PR Maturity highlights how well-prepared a PR is before being submitted.

• Quality indicator: Shows the readiness of work at submission.
• Efficient reviews: Higher maturity often leads to smoother, faster reviews.
• Process insight: Low maturity can signal a need for better pre-review checks, clearer acceptance criteria, or smaller PRs.

Total lines of code changed during the selected period.

Code Changes per day = (additions + modifications + deletions) ÷ days_in_period

Provides a high-level view of code volume and output. If you are 2–3 days into an iteration and this value remains low, it may indicate poorly defined tasks or hidden bottlenecks.

Total number of commits made in the selected period.

Commits per day = total_commits ÷ days_in_period

Shows commit activity levels and can be used to understand participation patterns over time.

Number of new pull requests created in the selected period.

PRs Opened per day = total_prs_created ÷ days_in_period

Measures how much work is entering the review pipeline and helps balance intake vs. completion.

Average number of PRs merged per day.

Merge Frequency = total_prs_merged ÷ days_in_period

A cadence signal for delivery momentum. A healthy merge frequency often correlates with smaller, more frequent releases.

Average number of deployments per day.

Deploy Frequency = total_releases ÷ days_in_period

One of the DORA metrics; it indicates how often code reaches users. Higher deploy frequency (with healthy quality) is associated with more adaptable, resilient teams.

Branches that reached a “Merged” or “Released” state in the selected period.

Count of branches with status in {merged, released}.

Tracks closure rate and helps ensure work is not left lingering as long-lived branches.

Normalized count of developer-days with code activity.

For each day, measure the fraction of team members who committed at least once. Aggregate across the selected period to produce a normalized value.

Highlights engagement consistency and broad participation across the team, rather than only counting raw volume.

*Metric available by request. To request, please contact your LinearB team.

Unique days with any Git activity (commits, PRs, reviews) in the selected period.

Count of unique days where developer activity > 0.

Shows participation patterns over time and can highlight potential burnout (activity every day) or idle periods.

Number of branches considered active (not merged or deleted) during the period.

• It has commits, PRs, or merges within the configured stale period (from any contributor).
• It has not been merged or closed by the end of the specified time window.

Count of branches with status = active.

Active Branches act as a proxy for WIP. Too many active branches can slow development flow and increase context switching.

The distribution of work types (for example, New Code, Refactor, Rework) over the selected period.

Helps you see whether engineering effort is aligned with strategy—such as balancing new feature work, maintenance, and refactoring.

Average time to restore service after a production incident.

Average duration from incident start to incident resolution:

MTTR = (sum of all incident resolution durations) ÷ (number of incidents)

A core DORA metric that captures resilience and recovery speed. Lower MTTR indicates the team can quickly mitigate customer impact when failures occur.

An Admin can define which issues represent incidents and which fields correspond to start/end times under: Company Settings → Project Management → Incidents.

Percentage of releases that cause a failure or incident.

CFR = failed_releases ÷ total_releases

CFR is a DORA metric that measures release quality and change stability. High CFR indicates that deployments frequently introduce production problems.

An Admin can define how LinearB recognizes incidents for CFR under: Company Settings → Project Management → Incidents.

Quantitative indicators for AI-assisted code reviews—for example, how often AI suggestions are accepted, ignored, or followed by further changes.

(Depending on your specific AI setup)

• Share of PRs that include AI review suggestions.
• Ratio of accepted vs. dismissed AI suggestions.
• Follow-up changes or rework on AI-assisted PRs.

AI Code Review metrics help you understand AI adoption and impact: how often AI is used, whether it is trusted, and where it adds—or fails to add—value in the review process.