Skip to main content

Time to Development Metric

Measures the time from PR merge until the deployment is first reported in the configured stage.

Steven Silverstone
Updated by Steven Silverstone

Overview

The Time to Development metric measures how long it takes for code to reach the configured Development stage after a pull request is merged.

This metric represents the first deployment stage pattern: pull request merge to the first deployment event reported for the configured stage.

Time to Development is available in dashboards, reports, and custom metrics views that support predefined metrics.

Time to Development is a custom stage metric. Stage names are configured by your organization and may differ from the Development stage shown in this article.
Time to Development requires multi-stage release tracking and deployment events to be configured in LinearB.

Calculating Time to Development

Time to Development is calculated as: 

First deployment reported in the Development stage - Pull request merge time

The timer starts when a pull request is merged and ends when LinearB receives the first deployment event reported for the configured Development stage.

Example

  • Pull request merged: Monday, 10:00 AM
  • Deployment first reported in Development: Monday, 12:30 PM

Time to Development = 2 hours 30 minutes

Aggregation Options

Time to Development supports the following aggregation methods:

  • AVG – Average Time to Development across all qualifying pull requests.
  • P50 – Median Time to Development.
  • P75 – 75th percentile Time to Development.
  • P90 – 90th percentile Time to Development.

The default aggregation is AVG.

Viewing the Metric

Time to Development is available as a predefined metric within LinearB.

When added to a dashboard, the metric displays the selected aggregation value for the chosen time period and filters.

The metric can be filtered using the same dimensions available for other delivery metrics, including teams, repositories, services, and time ranges.

Interpreting the Metric

A lower Time to Development value indicates that merged code is reaching the configured Development stage quickly.

A higher Time to Development value may indicate delays between merge and first deployment to the configured stage, such as:

  • CI/CD pipeline bottlenecks.
  • Deployment queue delays.
  • Manual approval requirements.
  • Release scheduling constraints.
  • Infrastructure or environment availability issues.

Monitoring Time to Development helps teams identify inefficiencies before code progresses to later deployment or release stages.

Limitations

  • Requires deployment events to be reported to LinearB.
  • Requires a configured Development stage within a multi-stage release workflow.
  • Only pull requests associated with tracked deployment events are included in the calculation.
  • The metric uses the first deployment event reported for the configured Development stage.
  • The stage name may differ depending on your organization's release pipeline configuration.
  • Time to Staging – Measures the time from the previous configured deployment stage until the deployment is first reported in the Staging stage.
  • Time to Release – Measures the time from the last configured deployment stage until the deployment is first reported in the Release stage.
  • Deploy Time – Measures the time required for code to move from merge to production deployment.

How did we do?

Time to Approve Metric

Time to Merge Metric

Contact