# Throughput and instability

Throughput and instability are the two groups DORA uses to read software delivery. Throughput is how many changes move through your system. Instability is how well your deployments go. The DORA 2025 report reads all five DORA metrics in these two groups, and Engineering Delivery reads them the same way: each team against its own recent past, never against tiers.

New to DORA? Start with [What is DORA?](/docs/engineering-delivery/what-is-dora) and [The five DORA metrics](/docs/engineering-delivery/dora-metrics), then come back here.

## What are throughput and instability?

DORA's 2025 report splits the five metrics into two groups (2025 report, page 13).

**Throughput** is "a measure of how many changes can move through the system over a period of time." DORA measures it with three metrics:

- [Change lead time](/docs/engineering-delivery/change-lead-time): the time from a change committed to version control to the change running in production.
- [Deployment frequency](/docs/engineering-delivery/deployment-frequency): the number of deployments in a period, or the time between them.
- [Failed deployment recovery time](/docs/engineering-delivery/failed-deployment-recovery-time): the time it takes to recover from a deployment that fails and needs immediate intervention.

**Instability** is "a measure of how well the software deployments go." DORA measures it with two metrics:

- [Change fail rate](/docs/engineering-delivery/change-fail-rate): the share of deployments that need immediate intervention, such as a rollback or a hotfix.
- [Deployment rework rate](/docs/engineering-delivery/deployment-rework-rate): the share of deployments that were not planned but happened because of an incident in production.

Higher throughput is better. Lower instability is better. DORA adds that "measuring these over time provides insight into how software delivery performance is changing" (2025 report, page 13).

## Why read the two groups together?

Because a team can get faster and break more things at the same time, and one number hides that.

DORA's research has long found that speed and stability are not a trade-off. In the 2025 report, the two strongest team profiles, pragmatic performers and harmonious high-achievers, do well on both at once. Together they are nearly 40% of the teams surveyed, and DORA calls the "speed vs. stability" trade-off "a myth" (2025 report, page 19).

The same report found that AI adoption now goes with higher throughput, but "it still increases delivery instability" (2025 report, page 4). So a team that adopts AI tools may well see throughput rise first. Reading instability next to it tells you whether the extra speed is safe. The [AI guide](/docs/engineering-delivery/ai#ai-against-the-rest) shows how to watch this for AI-assisted changes.

## What does good look like?

Better than your own past. The 2025 report publishes no performance tiers and no target figure for any metric. It publishes how the teams it surveyed answered, which the [Performance levels and benchmarks](/docs/engineering-delivery/performance-levels#how-do-you-compare-the-2025-spread-of-answers) page shows in full.

DORA is clear about how to compare: "the best, most insightful comparisons of software delivery performance are for the same application or service over time. The goal is continuous learning and improvement, not necessarily achieving top software delivery performance" (2025 report, page 20).

In practice, good looks like this:

- Throughput going up, or steady, while instability does not rise.
- Instability coming down after the team works on it, without throughput falling.

## How Solidafy reads them

In Engineering Delivery, open **Delivery**, then **Speed**. The **Throughput and instability** card reads the period you chose against the 90 days before it, for the team or teams in view. The same reading appears per team in the [Your teams](/docs/engineering-delivery/overview-and-focus#your-teams) table on the Brief.

### When a measure moves

Each measure is read for the period and for the 90 days before, from the same data as its tile.

- A time or a frequency moves when it changed by more than 10% of its earlier value.
- A rate, such as change fail rate, moves when it changed by more than 2 percentage points.
- Anything smaller is **steady**.

A measure is only compared when both windows have enough to read:

- lead time needs at least 5 merged changes in each window;
- deployment frequency, change fail rate and rework rate need at least 5 deploys in each window;
- recovery time needs at least 3 recoveries in each window.

With less than that, the card says **Not enough to compare**. A quiet month never reads as a change.

### How a group moves

A group got **better** when at least one of its measures got better and none got worse. It got **worse** the other way round. It is **mixed** when one measure got better and another got worse, and **steady** when none moved. The card shows each group in words: "Throughput up", "Instability down" and so on. Instability going up is never shown as good news.

### The delivery reading

The two groups combine into one reading, shown in words next to the card's title and in the Your teams table.

| Reading | When the app shows it |
| --- | --- |
| **Faster and steady** | Throughput got better, and instability did not get worse. |
| **Faster, less stable** | Throughput got better, but instability got worse. |
| **Steady** | Throughput was steady or mixed, and instability did not get worse. |
| **Less stable** | Throughput was steady or mixed, and instability got worse. |
| **Slower** | Throughput got worse. |

With no throughput reading, there is no delivery reading at all.

## Questions the app raises

### It says Faster, less stable. Is that bad?

It is worth a look, not a verdict. More changes are moving, and more of them need a fix or unplanned work. Look at the size of the changes and the review they get first: larger changes are harder to review and more likely to fail. See [Change size](/docs/engineering-delivery/review#change-size) and [Working in small batches](/docs/engineering-delivery/overview-and-focus#working-in-small-batches).

### It says Slower. Where do I start?

Open change lead time and look at [Where the time goes](/docs/engineering-delivery/speed#where-the-time-goes). It shows which step grew. Waiting for a first review is the most common one.

### Why the 90 days before, and not last month?

Ninety days is long enough to smooth out one odd week and short enough to stay close to how the team works now. It is the team's own recent past, so every team is read against itself.

### Why does it say Not enough to compare?

One of the two windows had too few changes, deploys or recoveries to read the measure fairly. Choose a longer period, or check that the deployment rule in Settings matches how the team deploys. See [Setting it up](/docs/engineering-delivery/setup).

## Learn more

Official sources used on this page:

- [DORA, State of AI-assisted Software Development 2025](https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf) (pages 4, 13, 19 and 20)
- [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics/)

Related Solidafy guides:

- [The five DORA metrics](/docs/engineering-delivery/dora-metrics)
- [Team profiles](/docs/engineering-delivery/team-profiles)
- [Performance levels and benchmarks](/docs/engineering-delivery/performance-levels)
- [Overview, focus and working agreements](/docs/engineering-delivery/overview-and-focus)