L2. DevOps Metrics and Dashboards: Cycle Time, Lead Time & Time to Recovery
The four DORA metrics, the difference between lead time and cycle time, and how a cumulative flow diagram makes a bottleneck stage visually obvious before it becomes a crisis.
Understanding DORA Metrics
The DORA metrics (DevOps Research and Assessment) are four key performance indicators that measure your organization's delivery capability. The AZ-400 exam tests all four, so understanding what each measures is critical.
The Four Core DORA Metrics
Deployment Frequency measures how often you release code to production. High-performing organizations deploy multiple times per day; low performers deploy monthly or less frequently. Lead Time for Changes measures the time from a code commit reaching main to that change running in production. This includes build, test, approval, and deployment time. Fast lead times (under a day) indicate rapid delivery capability. Change Failure Rate measures the percentage of deployments that result in incidents, rollbacks, or service degradation. Lower rates indicate more stable deployments and higher quality gate control. Mean Time to Recovery (MTTR) measures how long it takes to restore service after an incident. Fast recovery (under an hour) is better than slow recovery (days).Lead Time vs Cycle Time
These terms are often confused, so the exam tests the distinction carefully. Lead Time for Changes measures from the first code commit (or work item creation) to successful production deployment. It includes everything: development, review, build, test, approval, and deployment. Cycle Time measures from when work actively starts ("In Progress") to completion ("Done"). It is a narrower window that excludes planning and specification time.
In practice: Lead time is what matters for delivery speed; cycle time helps identify bottlenecks within active development.
Cumulative Flow Diagrams
A Cumulative Flow Diagram (CFD) visualizes the count of work items in each workflow state over time. The vertical axis shows the count; the horizontal axis shows time. Each colored band represents a state (To Do, In Progress, Code Review, Done).
When one band widens over time, work is piling up in that state. A widening "Code Review" band means reviews are a bottleneck. CFDs make bottlenecks immediately visible before they become crises.
Azure DevOps Dashboards and Widgets
Azure DevOps provides built-in widgets:
- Sprint Burndown and Burnup charts
- Velocity trends
- Cumulative Flow Diagrams
- Build and Release dashboards
For metrics beyond built-in coverage, use Analytics Views and the OData Analytics feed to power custom Power BI dashboards. This allows you to combine Azure DevOps data with external systems and refresh on your schedule.
Metrics Per Functional Area
Different stakeholders need different metrics:
- Planning team: velocity, burndown, sprint health
- Development team: PR cycle time, code churn, branch coverage
- Testing team: test pass rate, code coverage trends
- Security team: vulnerability count, vulnerability age
- Operations team: MTTR, incident count, deployment success rate
Designing dashboards per functional area ensures each group sees the metrics that matter to them. Exam tip: The AZ-400 exam emphasizes that metrics must be actionable and tied to business goals. A dashboard full of metrics nobody uses is worse than useless.
- ✓Lead time for changes measures from code commit (or work item creation) to successful production deployment; cycle time is the narrower window from "work started" to "done"
- ✓The four core DORA metrics tested are deployment frequency, lead time for changes, change failure rate, and mean time to recovery (MTTR)
- ✓A Cumulative Flow Diagram visualizes the count of work items in each state over time and is the standard tool for spotting where work is piling up (a bottleneck stage)
- ✓Azure DevOps Analytics Views and the OData Analytics feed let teams build custom Power BI dashboards for metrics not covered by out-of-the-box widgets
- ✓Dashboards should be designed per functional area (planning, development, testing, security, delivery, operations), not just one generic delivery metric, to match what each stakeholder group actually needs to see
1. Which metric specifically measures the time from a code commit reaching main to that change being successfully running in production?
2. A team notices that work items are piling up in the "Code Review" column of their board while other columns stay empty. Which visualization would make this bottleneck immediately visible?
3. A team needs a custom dashboard combining Azure DevOps work item data with data from an external system, refreshed on a schedule, beyond what built-in widgets support. What should they use?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.