Skip to main content

⭐️ Start here: Understanding and Configuring DORA Metrics

Learn how LinearB defines, calculates, and reports DORA metrics across your organization. Start with how releases and incidents are detected, then review how Change Failure Rate (CFR) and Mean Time to Restore (MTTR) are calculated and tuned—so your DORA metrics accurately reflect real delivery and recovery performance.

Steven Silverstone
Updated by Steven Silverstone

Start here to understand how LinearB defines, calculates, and reports DORA metrics across your organization. These articles walk you through how releases and incidents are detected, how Change Failure Rate (CFR) and Mean Time to Restore (MTTR) are calculated, and which configuration choices most affect accuracy.

Summary
  • Start with how LinearB detects releases (your deployment signal).
  • Then configure incident detection (your failure and recovery signal).
  • Review how CFR and MTTR are calculated and how to tune them.
  • Use the improvement article to reduce CFR through smaller, safer deployments.
Recommended reading order
  1. How LinearB Detects Releases for DORA Metrics — confirm how deployments/releases are identified.
  2. Incident API – Configure Incident Detection for DORA Metrics — choose and configure incident signals (PM tool or API).
  3. Change Failure Rate (CFR): Definition and Calculation — understand what counts as a failure and how CFR is computed.
  4. Mean Time to Restore (MTTR): Definition and Calculation — understand recovery windows and how MTTR is computed.
  5. Reducing Change Failure Rate Through Smaller Deployments — apply practical strategies to improve CFR.
What you should configure first
  • Release detection: ensure your release detection strategy matches how your teams ship (for example, tag-based vs merge-based).
  • Incident detection: define what a “production incident” means in your environment (PM-based rules or Incident API reporting).
If release or incident detection is misconfigured, CFR and MTTR may still compute—but the results may not reflect real delivery and reliability performance.

How did we do?

Reducing Change Failure Rate Through Smaller Deployments

Contact