How to build a DORA metrics dashboard
A DevOps DORA metrics dashboard is crucial for understanding how effectively your teams develop, deliver, and maintain software. Rather than relying on anecdotal evidence or isolated reports, DORA metrics provide a research-backed framework for measuring delivery performance and operational stability.
By combining these metrics into a single unified view, you move from reactive reporting to operational intelligence.
In this article, we’ll build a dashboard that brings the four DORA signals together in one unified view. By correlating deployments with failures, incidents, and recovery time, you'll create a real-time view of delivery performance and stability.
What are DORA metrics?
DORA (DevOps Research and Assessment) metrics focus on four key indicators that predict software delivery performance:
- Deployment Frequency: How often you deploy to production.
- Lead Time for Changes: How long it takes for code to reach production after commit.
- Change Failure Rate: The percentage of deployments that cause incidents or require remediation.
- Mean Time to Recover (MTTR): How long it takes to recover from failure.
Configuring tiles
Each tile is a focused signal. Together, they form a clear picture of delivery performance and operational stability.
You can follow them sequentially or implement them independently. However, complete the composite performance or risk view last, as it relies on signals from the others.
Deployment frequency
Deployment frequency measures how often code reaches production.
High frequency reduces batch size and risk per change. Low frequency often hides large, risky releases.
Average deployment count
This tile displays a simple count of the average deployments per day. It provides a clear, at-a-glance view of delivery throughput and helps teams understand how frequently changes are reaching production.
See how to create a deployment frequency tile for detailed instructions.
Deployment timeline
This tile shows when deployments have occurred and how frequently changes are being pushed. It helps teams understand deployment cadence and provides context when investigating incidents or regressions that may align with recent releases.
See how to create a deployment frequency over time tile for detailed instructions.
Lead time
Lead time tracks how long it takes for a change to move from commit to production. It measures the total elapsed time between a developer beginning work on a change (typically the first commit or pull request creation) and that change being successfully deployed to a live production environment.
Short lead times typically indicate small batch sizes and clear ownership. Long or highly variable lead times often signal systemic inefficiencies that increase delivery risk.
Lead time average
This tile displays the average lead time in hours. It measures how long it takes for a change to move from initial commit to successful production deployment, providing a clear indicator of delivery flow efficiency.
See how to create an average lead time tile for detailed instructions.
Lead time timeline
This tile displays a line graph of lead times over time. It visualizes how long changes are taking to move from commit to production and highlights trends, spikes, and variability that a single average value can hide.
See how to create a lead time frequency tile for detailed instructions.
Change failure
Change failure measures how often deployments result in user-impacting issues. It reflects the reliability of your delivery process and answers a critical question: when we ship changes, how often do they cause problems?
By correlating deployments with incident data, you move beyond pipeline success metrics and measure real-world impact.
Change failure rate
This tile models change failure rate by correlating successful build runs with incident-level bugs. Successful builds represent changes that were eligible to reach production, while incident-priority bugs represent negative, user-impacting outcomes.
See how to create a change failure rate tile for detailed instructions.
Deployment failures
This tile focuses specifically on failed deployment attempts within your pipeline. While change failure rate measures post-release impact, this tile measures pipeline reliability.
A rising deployment failure rate often precedes rising change failure rate, making this an early warning signal.
See how to create a deployment failures tile for detailed instructions.
Mean time to recover (MTTR)
MTTR
MTTR (mean time to recover) tracks how quickly it takes you to resolve an incident. Viewed alongside alert volume, they show whether noise is slowing response times or extending incident duration.
See how to create an MTTR tile for detailed instructions.
Incidents
This tile displays a bar chart showing the number of incidents over a given time period.
See creating a daily incidents tile for detailed instructions.
Next steps
You now have a dashboard that brings the four DORA metrics together into a single, coherent view of delivery performance.
Instead of relying on scattered reports or assumptions, these tiles provide operationally intelligent signals showing how frequently you deploy, how quickly changes move through your pipeline, how often they cause issues, and how fast your teams recover.
To get the most value from this dashboard:
- Review it before major releases to understand recent deployment activity.
- Use it during retrospectives to ground discussions in real delivery data.
- Track trends over time to identify improvements or emerging bottlenecks.
- Compare services or teams to highlight areas of operational risk or friction.
Over time, this dashboard shifts your focus from reactive troubleshooting to understanding and improving the systems behind software delivery.
When engineering decisions are guided by clear signals rather than instinct, teams gain something powerful: clarity, confidence, and above all operational intelligence.