What each measures and the real trade‑offs you’ll hit

DORA tracks four signals: deployment frequency, lead time for changes, change failure rate, and mean time to restore service. Use it when the question is whether delivery speed is improving without degrading reliability (source: Google Cloud DORA 2023 Accelerate State of DevOps Report).

Shipping cadence reports track week-level rhythm: shipped items, merged PRs, and merge-to-production flow. They expose batch size and flow efficiency, not incident quality. Git and PR activity can support this cadence view when the underlying repository and CI events are consistent enough to compare over time (source: GitHub Octoverse 2023 (consulted 2026-07)).

View	What it answers	Data dependency
DORA dashboard	Are delivery and reliability outcomes getting better?	Clean production deploy events plus incident-to-change mapping
Shipping cadence report	Is the team shipping in a steady flow or batching work?	VCS and CI data; minimal release modeling

The trade-off is setup cost. DORA needs production deploy identity and incident links; weak mapping makes change failure rate and MTTR unreliable. Cadence can start from GitHub or GitLab merges and CI runs before incident taxonomy is mature.

The views can disagree. In a hotfix-heavy week, deployment frequency may rise while shipped-item count stays flat because engineers are reworking. In a bundled-release week, cadence may rise while change failure rate worsens if the batch hides risky changes.

💡

Choose DORA when the question is stability and reliability; choose cadence when the question is throughput, batch size, or flow bottlenecks.

Answering exec and team questions in 15 minutes

Start from Git, CI, and incident events, then switch the lens by audience. The metric set changes; the source tables do not.

Board / executive

Show lead time and change failure rate as trends, not isolated snapshots. Add a short narrative: release freeze, incident cleanup, or review queue changes.

Add shipping cadence beside them to show delivery momentum. Treat cadence as context, not a success proxy when failure rate rises.

Product risk

Break cadence down by product area and compare it with planned scope. A quiet area with committed work can signal slip risk early.

Track PR age buckets to expose creeping WIP. Old open PRs can point to unclear ownership, oversized scope, or blocked review paths.

Team coaching

Use median PR size, time-to-merge, and rollback events to locate friction. Do not turn them into individual scorecards.

For a one-slide view, put DORA first, cadence second, and data freshness plus caveats in the footer. Keep charts small and comparable.

Minimal data model to calculate both from GitHub/GitLab + incidents

Keep the shared grain at one production deployment per service. Store these core fields: deployment_id, service, commit_sha, pr_id, merged_at, deployed_at, incident_id, incident_opened_at, incident_resolved_at, and change_failed.

Pick one production deploy source

Infer deploys from tags or releases, CI pipeline names, or environment events. Choose one production source of truth per service, otherwise the same deploy can appear as a tag, a pipeline, and an environment update.

Attach incidents to deployments

For each incident, map incident_opened_at to the latest deployment_id for the same service before the incident started. Set change_failed=true on that deployment when the incident represents a production failure.

Attribute fixes without double counting

Treat reverts and roll-forwards as remediation actions for the initiating deployment. Do not count the revert deploy as the failed change when it only restores or replaces the bad release.

Make the pipeline auditable

Use one timezone across Git, CI, and incident data. Make backfills idempotent. Enforce primary keys on (service, deployment_id). Keep an auditable mapping table from incidents to deployments, including manual overrides.

💡

If incident ownership is ambiguous, leave change_failed unset until a reviewer approves the incident-to-deployment mapping. A blank value is safer than a guessed failure label.

Equations, windows, and sampling that won’t lie to you

Lead time is measured per PR: deployed_at - merged_at, only after the PR maps to a successful production deployment. Deployment frequency is count(successful_prod_deploys) grouped by service and week (source: Forsgren, Humble, Kim — Accelerate (2018)).

Change failure rate is failed_prod_deploys ÷ total_prod_deploys. A failed deployment must match a written team definition: rollback, hotfix, incident, or customer-impacting degradation. MTTR is incident_resolved_at - incident_opened_at for incidents linked to production change (source: Google Cloud DORA 2023 Accelerate State of DevOps Report).

Use a 4-week window for team flow because it reacts to recent delivery changes (source: Google Cloud DORA 2023 Accelerate State of DevOps Report). Use a 12-week window for executive stability because it reduces noise from isolated incidents (source: Google Cloud DORA 2023 Accelerate State of DevOps Report). Plot per-service small multiples, not a single average, so a stalled service cannot hide behind a fast one.

Do not show rates until the denominator is large enough for the team to trust the sample. Exclude non-production deploys and automated deploys from production metrics. Annotate anomalous events, such as a planned migration freeze or provider outage, instead of deleting them from the dataset.

A hybrid scorecard you can ship this week

Make the slide three rows. Row 1: the DORA 4 metrics with 4- and 12-week trends (source: Forsgren, Humble, Kim — Accelerate (2018)). Row 2 should show cadence from the warehouse tables: shipped items or PRs per week, median PR size, and median time-to-merge (source: GitHub Octoverse 2023 (consulted 2026-07)). Row 3 should be a quality gate for escaped defects, sourced from incident or bug labels.

Use a fixed weekly operating loop. Monday: ingest Git, CI, deployment, and incident data; run QA checks for missing deploy IDs and reopened incidents. Tuesday: each team reviews its row, adds one short “what changed” note, and links the relevant experiment or incident. Wednesday: send the exec update with the same slide, not a rewritten version.

Show trends and deltas before targets. Rotate the spotlight metric so teams do not optimize only lead time or PR size. Tie goals to named experiments, such as “split database migrations from app deploys,” not to raw-number mandates.

Version every metric definition, publish the schema, and require PRs for definition changes. Each PR needs an effective date, the affected columns, and the expected dashboard diff.

Create the scorecard skeleton

Start with one reviewed schema file and one weekly slide; reject metric changes that bypass PR review.

DORA Metrics Dashboard vs Shipping Cadence Reports: When to Use Each