Skip to main content

Time to Staging Metric

Measures the time between the first deployment reported in the previous stage and the first deployment reported in the configured stage.

Steven Silverstone
Updated by Steven Silverstone

Overview

The Time to Staging metric measures how long it takes for code to move from the previous configured deployment stage to the configured Staging stage.

This metric represents the additional deployment stage pattern: the time between the first deployment event reported for the previous stage and the first deployment event reported for the current stage.

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

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

Calculating Time to Staging

Time to Staging is calculated as:

First deployment reported in the Staging stage - First deployment reported in the previous deployment stage

The timer starts when LinearB receives the first deployment event reported for the previous configured stage and ends when LinearB receives the first deployment event reported for the configured Staging stage.

Example

  • Deployment first reported in Development: Monday, 10:00 AM
  • Deployment first reported in Staging: Tuesday, 2:00 PM

Time to Staging = 28 hours

Aggregation Options

Time to Staging supports the following aggregation methods:

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

The default aggregation is AVG.

Viewing the Metric

Time to Staging 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 Staging value indicates that code is progressing efficiently between deployment stages.

A higher Time to Staging value may indicate delays such as:

  • Extended testing cycles.
  • Manual promotion processes.
  • Release approval requirements.
  • Environment availability constraints.
  • CI/CD pipeline bottlenecks.

Monitoring Time to Staging helps teams identify delays between deployment stages before code progresses further through the release pipeline.

Limitations

  • Requires deployment events to be reported to LinearB.
  • Requires configured deployment stages 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 each configured stage.
  • The stage names may differ depending on your organization's release pipeline configuration.
  • Time to Development – Measures the time from pull request merge until the deployment is first reported in the configured 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 Review Metric

Contact