The following four metrics are the key performance indicators for successful software organizations found by the DevOps Research and Assessment (DORA):

  • Lead Time for Changes - The time it takes for a change to make it from idea into production
  • Deployment Frequency - How often an organization successfully releases to production
  • Change Failure Rate - The percentage of deployments causing a failure in production
  • Mean Time to Recovery - How long it takes an organization to recover from a failure in production

While there is an abundance of literature available to explain how these metrics are calculated and why they are important, few of these literary resources offer visualizations.

Why does nobody use the power of visualization to introduce the abstract concepts of the four DevOps metrics?

We don’t know either, but we changed it. :)

Let’s start with a visualization you probably already know, the widely used DevOps loop:

DevOps loop

The DevOps loop visualizes nicely:

  • the closing of the gap between software development (Dev) on the left, and the operations (Ops) on the right by merging of the previously separated feedback loops.
  • the continuous, cyclical flow of feedback and improvement changes by the infinity symbol.

We will use the DevOps loop to explain concepts and introduce recognizable symbols for the four key metrics.

Lead Time for Change

A definition for Lead Time could sound like:

Time for value to be delivered to the stakeholders after the change has been identified as value to add.

Pretty abstract, do you want it simpler? It’s the time from when an idea flashes up Light bulb until happy users Happy user can enjoy its benefits.

Combining that with the DevOps loop, it’s the time from when an idea enters the loop in Plan phase, travelling through the loop until it reaches Operate phase, when users can start using it.

Lead Time

Deployment Frequency

To understand this metric, we first need to answer what a frequency is?

We actually know one by heart, literally. Our heartbeat is a well-understood frequency.

Tracking the Deployment Frequency of a software organization/project is similar to checking health of a living creature by measuring the heartbeat Heartbeat of it.

Like a heart is pumping fresh blood through the body with every beat to keep it alive, every deployment allows new improvements to be released to the end users to keep them delighted.

In the context of the DevOps loop, the Deployment Frequency is measuring the throughput as changes leave Deploy phase and reach the happy users in Operate phase.

Release Frequency

Change Failure Rate

In the intro section, we defined the Change Failure Rate as:

The percentage of deployments causing a failure in production.

That’s not too hard to understand.

For percentage and failure there are already generally accepted symbols % and X, respectively, resulting in Failure

We make the link to deployment and the DevOps loop by positioning these two symbols at the end of the highlighted Deploy phase.

And so we have a simple, yet recognizable icon for the Change Failure Rate:

Change Failure Rate

Mean Time to Recovery

Even if your Change Failure Rate is already low, failures will still happen.

Because they cannot be eliminated completely, it’s important to be able to detect, react, and fix the causes of failures ASAP.

The priority is to make production green and your users happy Happy user again.

In DevOps loop terms, Mean Time to Recovery is: The time from when a failure occurs and enters the loop in the Operate phase, until a fix flows out of the Deploy phase and restabilizes the system.

So let’s use that as recognizable visualization for our last metric, Mean Time to Recovery:

Mean Time To Recovery


We, the team behind, think it’s important to understand the key concepts of the four key metrics.

It helped us to visualize the core concepts of each metric and the relationships between them while prototyping our new, integrative SaaS product DevSensei. We hope that by sharing these visualizations, we can help the community better understand the interconnections and flow of DevOps.