> ## Documentation Index
> Fetch the complete documentation index at: https://docs.periscope.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Change failure rate

> Percentage of deployments that fail. The third DORA metric and a key measure of release quality.

Change failure rate (CFR) measures the percentage of production deployments that result in a failure. It is a direct indicator of release quality — how often does shipping code break something?

## What Periscope tracks

Periscope calculates CFR from your deployment events. The dashboard shows:

* **Overall failure rate** as a percentage
* **Total deployments** and **failed deployments** count
* **Failure rate by service** to identify which services are most failure-prone
* **Recent failed deployments** with details (service, time, pipeline URL)

## DORA benchmarks

| Level      | Benchmark |
| ---------- | --------- |
| **Elite**  | 0-5%      |
| **High**   | 5-10%     |
| **Medium** | 10-15%    |
| **Low**    | 15%+      |

## How it is calculated

```
change_failure_rate = failed_deployments / total_deployments * 100
```

Periscope counts deployments to production with `status: "failure"` against the total number of production deployments (any terminal status) in the selected time range.

The per-service breakdown applies the same formula scoped to each service name in your deployment data.

## Interpreting the data

* **Low CFR with high deployment frequency** is the ideal state — you are shipping often and reliably.
* **High CFR with low deployment frequency** is the most dangerous pattern — infrequent, large deployments that often break.
* **One service with high CFR** while others are healthy suggests a problem specific to that service's test coverage, complexity, or deployment process.
* **CFR trending upward** may indicate degrading test quality, increasing system complexity, or a growing gap between development and production environments.

### Reducing change failure rate

* Ship smaller changes more frequently (smaller blast radius)
* Improve pre-merge CI — catch failures before code reaches production
* Add canary or staged rollout strategies
* Implement feature flags to decouple deployment from release
* Review failed deployments in Periscope to identify patterns

## MCP tool

Query change failure rate from your AI coding assistant:

```
get_change_failure_rate(time_range: "30d")
```

Returns total deploys, failed deploys, failure rate percentage, per-service breakdown, and the 10 most recent failures.

<Card title="Mean time to recovery" icon="rotate" href="/metrics/mttr">
  When failures happen, MTTR measures how fast you recover.
</Card>