Change Failure Rate Report

Last updated: October 27, 2026

Change failure rate (CFR) shows how many production incidents you have for each successful production deployment, as a percent. It is Span's stability counterweight to deployment frequency on the DORA page.

Why it matters

CFR answers "How much reliability trouble comes with each production deploy?" Lower is better. Use it to:

  • Balance speed and stability: compare CFR with Deployments / week. Frequent deploys with a low CFR is the goal. Frequent deploys with a rising CFR means you are moving fast and breaking things.

  • Track the effect of process changes: did more automated tests, a new review process, or staged rollouts lower CFR?

  • Spot trends early: a sudden rise points to recent system, process, or team changes worth investigating.

  • Compare teams: find teams whose practices are worth sharing and teams that need support.

How it works

Change failure rate = (production incidents ÷ successful production deployments) × 100

Both counts cover the same date range.

  • Incidents (numerator): every incident created in the range whose environment is blank or contains "prod" or "prd", in any letter case. Incidents come from incident.io, Rootly, or Span's DORA API. incident.io and Rootly incidents carry no environment, so all of them count. Every severity and status counts.

  • Deployments (denominator): every deployment in the range with status success and an environment that is blank or contains "prod" or "prd". Span dates each deployment by when it was triggered. Rollbacks and restarts count. Pending and failed deployments don't.

  • No deployments: if a range has no successful production deployments, CFR shows 0%.

Span divides the two totals. It doesn't trace each incident back to the deployment that caused it. The DORA API accepts triggeringDeployments on an incident and stores it, but CFR doesn't use it today.

Teams. A team's CFR is the team's incidents divided by the team's deployments. Incidents reach a team through their owner teams (the incident.io team field, Rootly team mappings, or owners on the API). Deployments reach a team through the teams that own their services, or through the authors of linked PRs when Span has turned on deploy-to-PR linking for your organization. Records with no team count in your organization total only. CFR has no per-person view.

Where to find it. Go to Insights → Productivity → DORA. You can also add Change failure rate to a custom dashboard.

Setup

  1. Send deployments. Span has no connector that reads deployments from GitHub Actions, GitLab CI/CD, or Azure DevOps. Add a step to your pipeline that calls Span's DORA API (POST /api/dora/v1/deployments with status: "success") or sends a $deploy event.

  2. Send incidents. Connect incident.io or Rootly in Settings → Integrations, or send incidents through the DORA API (POST /api/dora/v1/incidents). Span has no PagerDuty or Opsgenie connector; use the DORA API for incidents from those tools.

  3. Map both to teams. Give each service an owning team, and map incidents to teams in your incident integration or with owners on the API.

  4. Open Insights → Productivity → DORA and check the Change failure rate chart.

Things to know

  • Span's CFR differs from DORA's definition. DORA counts the share of deployments that caused a failure. Span divides the raw incident count by the deployment count. Treat it as a trend indicator, and compare against your own history rather than published DORA bands.

  • Worked example. In a month you ship 40 successful production deployments. One of them causes 3 incidents, and 1 more incident has nothing to do with a deploy. Span shows 4 ÷ 40 = 10%. A strict DORA count would show 1 failed deployment ÷ 40 = 2.5%.

  • CFR can exceed 100%. A team with 2 incidents and 1 deployment in the range shows 200%. This usually means the team's deployments aren't reaching Span or aren't mapped to the team.

  • Team mapping must line up on both sides. If incidents map to a team but its deployments don't, or the reverse, the team's CFR looks very high or reads 0%.

  • Declined, canceled, and low-severity incidents count. There is no setting to exclude them. Through the DORA API you can send only the incidents you want counted, or give the rest a non-production environment.

  • Rollbacks count as deployments. A rollback with status success adds to the denominator. A failed change raises CFR only if it also produced an incident.

  • Hotfixes. A hotfix deploy counts as a deployment like any other. If your team handles some failures with a hotfix and never opens an incident, send an incident for each one through the DORA API so CFR counts the failure.

  • Severity isn't weighted. Five minor incidents and five outages give the same CFR. Read severity alongside it.

  • Don't deploy less to lower CFR. Fewer deployments raise CFR for the same incidents and defeat the purpose. Aim for frequent deploys and a low CFR together.

  • 0% with frequent deploys? Check that incidents are reaching Span in Catalog → Incidents.

  • Older DORA setup. If Span set your organization to the older version of the DORA page, the incident count comes from Jira issues that match your critical-bug rules in Settings → Metrics.

Related articles

Mean Time To Recover (MTTR) Report

Deployments / Week

Lead Time to Production in Span

How to use the DORA API to send deployment activity to Span

How does the Incident.io integration work?

Rootly Integration

Need help?

Contact your Span account team or reach out to support@span.app.