Design and implement processes and communications
DevOps Metrics and Queries
CoreTurn planning, development, test, security, delivery, and operations data into metrics and queries with explicit populations, time boundaries, owners, and decisions.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
A dashboard can make the wrong behavior look precise. Expert practice defines the operational question first, then chooses events, dimensions, windows, and thresholds that support a decision.
Must Know
- Lead time measures from request or work creation to completion; cycle time measures active work; time to recovery measures restoration after a service failure.
- Planning uses ready backlog, work in progress, historical throughput or velocity, burnup, and forecast evidence rather than undifferentiated ticket counts.
- Development flow can use pull-request age, review wait time, merge rate, and work in progress, but commit counts alone reward activity rather than value.
- Testing queries should distinguish pass rate, duration, failure ownership, and flaky tests across repeated runs.
- Security queries need finding type, severity, age, repository, owner, exploitability or exposure context, and remediation state.
- Delivery metrics require consistent definitions for production deployment, deployment frequency, lead time for changes, and change failure.
- Operations evidence combines availability, latency, errors, saturation, incident duration, and restoration with release markers.
Compare and Distinguish
- Lead time begins before active implementation; cycle time begins when work starts.
- Deployment frequency measures release flow; change failure rate measures harmful production outcomes; time to recovery measures response after failure.
- A point-in-time status chart answers a different question from a trend or control chart.
Scenario examples
- Scenario: Managers ask whether review is the delivery bottleneck. Think: measure pull-request wait and active review time, not commits per developer.
- Scenario: On-call wants to compare incidents with releases. Think: use deployment markers and consistent incident start, restore, and close events.
Exam traps
- Averages can conceal a slow service, repository, region, or percentile.
- Changing a work-item state definition breaks trend comparison unless history is reconciled.
- A metric without owner, target, or decision rule becomes a vanity measure.
Key takeaways
- Define event boundaries before calculating duration.
- Segment by the dimensions that can change the decision.
- Use a small balanced dashboard rather than one score that erases cause.
How it works
- Queries select well-defined records and dimensions; widgets then aggregate those records into trends, queues, or service-level evidence.
- Deployment markers connect delivery events to operational signals without claiming that correlation alone proves causation.
Objects and administrative surfaces
- Azure Boards queries, Analytics views, dashboards, cumulative flow, lead time, cycle time, velocity, and Power BI.
- Azure Pipelines Analytics reports, test results, security findings, deployment history, and Azure Monitor workbooks.
When to use it
- Use a purpose-built query when a stakeholder must filter, own, or act on the underlying records, not merely see a total.
Security and governance implications
- Restrict dashboards containing vulnerability or incident detail and retain the underlying source records used for decisions.
Troubleshooting signals
- When a trend shifts, check scope, state transitions, time zones, missing records, and definition changes before changing delivery behavior.
More detail
- Separate lead time, active cycle time, deployment frequency, change failure rate, and restoration time by their event boundaries.
- Forecast work from a prioritized ready backlog and observed team throughput rather than from ticket or commit volume.
- Preserve dimensions such as repository, team, severity, test name, environment, and release so aggregates do not hide bottlenecks.
Ready for the quiz?
- What start event separates lead time from cycle time?
- Which metric identifies intermittent test behavior?
- Why is deployment count alone insufficient for delivery performance?
Related objectives
- D1.2.S1 — Design and implement a dashboard, including flow of work, such as cycle times, time to recovery, and lead time
- D1.2.S2 — Design and implement appropriate metrics and queries for project planning
- D1.2.S3 — Design and implement appropriate metrics and queries for development
- D1.2.S4 — Design and implement appropriate metrics and queries for testing
- D1.2.S5 — Design and implement appropriate metrics and queries for security
- D1.2.S6 — Design and implement appropriate metrics and queries for delivery
- D1.2.S7 — Design and implement appropriate metrics and queries for operations