Four delivery numbers the board can trust,
from deploys that really happened.
Datadog DORA Metrics builds deployment frequency, change lead time, change failure rate and recovery time from the deployment events your pipeline and your traces already produce. AI Impact splits them by whether an AI coding tool was involved. We wire the events, set the failure rules to match your practice, and run it every month so the figures still describe the delivery.
Quick facts
Related
- CI Visibility, the pipeline the deployment events come from
- Incident Management, the incidents the recovery time is measured on
- Internal Developer Portal, the teams and services the figures are grouped by
The delivery slide, built from events instead of memory
The quarterly review asks how often the team deploys. Someone counts the release tags, someone else counts the pipeline runs, and the two numbers differ by a factor the room cannot explain. DORA Metrics counts the deployments that reported a new version into production, so the number is the same whoever asks.
Deployment frequency from real deployments. A deployment is an event: a service started reporting a new version, a pipeline job said it deployed, or a release tool called the API. Not a tag someone remembered to push.
Lead time from commit to production. With the repository linked, each deployment carries its commit, and lead time is measured from the commit's creation to the first time that version served traffic. The number includes the wait, not just the build.
Failure and recovery from rules you can read. A redeploy of an earlier version is a rollback. A revert pull request or a hotfix label is a rollforward. The rules are visible and editable, so the failure rate means what your teams mean by failure.
AI Impact, split honestly. Pull requests with an AI-assisted commit compared against the rest on throughput, cycle time, failure rate and recovery, detected from commit metadata, integrations and labels. In Preview, and labelled as such on every report.
A version tag that never changes, a failure rule nobody matched to practice, and a lead time that forgot the commit
How it bills. DORA Metrics is computed from events other Datadog products and integrations produce, and Datadog's pricing page does not list a separate meter for it. Deployment events come from APM Deployment Tracking, which needs APM and unified service tagging, or from the DORA API and datadog-ci, which send events directly. Change lead time needs the repository and commit on each event, plus the GitHub or GitLab source code integration or a git metadata upload. AI Impact is in Preview. We confirm the arrangement on your contract before scoping. We publish nothing here, because the price is not the problem. Whether every deployment is an event is.
The configuration traps. APM Deployment Tracking needs the version tag to change on every release. A service whose version is set once in a config file deploys daily and reports a frequency of zero. The datadog-ci event is added to one pipeline template and not the other, so half the estate deploys invisibly. Lead time needs the repository and commit on the event, and the option that skips git to speed up the job removes them. The failure rules default to revert pull requests and hotfix labels, and a team that fixes forward with a commit message convention instead has a change failure rate of zero and a recovery time of nothing. None of these raises an error. They produce a slide with confident numbers that describe a different organisation.
Field noteThe most common gap we see is deployment frequency that is really pipeline coverage. The services whose pipelines send the event look fast. The services whose pipelines were templated before the event was added look frozen, and the comparison between teams is a comparison between pipeline templates.
Field noteThe failure rules were left at the defaults, which look for revert pull requests and hotfix labels. The team fixes forward rather than rolling back, marks fixes with a prefix in the commit message, and never labels anything. The change failure rate is zero for a quarter in which the on-call rota remembers several hurried fixes.
Field noteThe pattern we keep finding is a lead time that covers half the estate. The deploy job runs datadog-ci with the option that skips git, to save a few seconds, so the event arrives without the repository and commit and Datadog cannot calculate change lead time for that service. The headline figure describes only the services that kept git.
Field noteAI Impact is switched on and the AI-assisted share is near zero, which is reported upward as evidence the tool is unused. The coding assistant in question does not add a co-author line, no integration, label or mapping rule was set up for it, and the number is about the detection rather than the adoption.
Every deployment an event. Every event a commit. Failure rules matched to practice before any number leaves the room.
DORA Metrics depends on APM for version tracking and on the pipeline for events, so it follows both. The Software Delivery Accelerator brings the pipeline into Datadog and builds the deployment frequency and lead time views in four weeks, fixed scope. If APM and CI Visibility already run, a Datadog HealthScan reports which services emit deployment events and whether the version tag moves, before we change anything. Either way, the sequence is the same.
- Inventory the deployment paths. Which services deploy through which pipelines, which through a release tool, which by hand. Each path gets an event source: version tracking, datadog-ci or the API.
- Make the version tag move. The version in unified service tagging comes from the build, not a file. We check a release in staging produces a new version in APM before relying on it.
- Send events with the commit attached. The datadog-ci deployment command in every deploying job, in every pipeline template, with repository and commit inferred from the checkout. The git-skipping shortcut stays off.
- Link the repositories. The GitHub or GitLab integration syncs repository metadata so lead time runs from commit creation, not from pipeline start.
- Write the failure rules to match the practice. We read a quarter of real rollbacks and fixes with the teams. Then we set the rollforward rules to the labels, branch names or message conventions they actually use. The rules are tested against those known incidents.
- Hand over, in writing. The event source per service, the version tag mechanism, and the failure rules with the incidents they were tested against. The AI Impact sources and mapping rules if enabled. The four figures by team on the day we finished, with the caveats.
Access is admin on the Datadog organisation plus a pull request into the pipeline templates and the source provider integration. We do not need production shell access to implement DORA Metrics, and we do not ask for it.
A metric that nobody reconciles drifts into fiction within a quarter
A new service deploys through a pipeline template without the event. A team changes how it marks a hotfix. A new AI tool arrives with a different signature. Managed Observability is the monthly service that keeps the four figures describing the delivery that happened.
Every month, we reconcile the events. Deployment events per service against the deploys the pipelines ran. A service that went quiet is a missing event before it is a slowdown, and we say which.
Coverage follows the services. New services and environments get an event source in the month they ship. A new pipeline template gets the deployment command before it is copied.
The failure rules are kept honest. The month's real incidents and rollbacks are checked against what the rules detected. A rollback the rules missed is a rule to fix, and we fix it before the figure is issued.
The recovery time is ours to move. Under Critical Support our engineers answer the alert a failed deployment raised, 24x7, and fix the cause rather than report it. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.
We operate the stack. You own the product.
An implementation partner wires the events and hands over a dashboard. A managed partner is still there when a pipeline template drops the event in March and a team's frequency falls to zero. We are the second kind. The event sources, the failure rules, the dashboards and the decisions stay in your Datadog organisation and your pipelines, documented, and you can take them in-house whenever you choose. What the figures mean for your teams is a conversation for your engineering leadership. We make sure the figures are true first.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog DORA Metrics, answered plainly
How is Datadog DORA Metrics billed?
DORA Metrics is computed from events that other Datadog products and integrations produce, and Datadog's pricing page does not list a separate meter for it. Deployment events come from APM Deployment Tracking, which needs APM and unified service tagging, or from the DORA API and the datadog-ci tool, which send events directly. Change lead time needs the repository and commit on each event, plus the GitHub or GitLab source code integration or a git metadata upload. AI Impact is in Preview and available to all Datadog customers on the commercial sites, including Datadog's UK region. We do not publish prices, and we confirm the arrangement on your contract before scoping. Which services send deployment events, and how failures are defined, is what we tune.
Where do the deployment events come from?
Three places, and you can use more than one. APM Deployment Tracking detects a deployment when a service starts reporting a new version tag, which needs unified service tagging to be in place. The datadog-ci tool sends a deployment event from the pipeline job that deploys. The DORA API accepts an event from anything else, including a release tool Datadog has never heard of. Each event needs the service name and the start and finish times. For change lead time it also needs the repository and the commit, which the CLI can infer from the pipeline.
How does Datadog decide a deployment failed?
By rules you can see and change. A rollback is detected automatically when a previously deployed version is deployed again. A rollforward is detected by default rules such as a revert pull request or a hotfix label, and those rules can be customised in the DORA settings to match how your teams actually mark a fix. Change failure rate and recovery time are built from those detections, so if the rules do not match your practice, the numbers do not describe your delivery. We check the rules against the last quarter of real incidents before anyone reports a figure upward.
What is AI Impact?
A view inside DORA Metrics that compares delivery performance for work assisted by AI coding tools against work that was not. It reports the share of pull requests with an AI-assisted commit, throughput and cycle time for assisted versus unassisted authors, and change failure rate and recovery time weighted by the share of AI-assisted commits in each deployment. It detects AI activity from co-author signatures in commit metadata, provider integrations, pull request labels and data you send yourself, with mapping rules for your specific tools. It is in Preview, and we say so on any report that uses it.
What does Critical Cloud do with DORA Metrics every month?
Managed Observability runs it every month. We reconcile the deployment events against the deploys the pipelines actually ran, so a service that stopped sending events is caught before its frequency looks like a slowdown. We check the failure rules against the month's real incidents and rollbacks. We add new services and environments. Then we produce the four figures by team, with a note on what changed in the data. Acting on the figures is your engineering leadership's job, and we give them numbers they can defend.
- Datadog products: every product, and how we implement and run each one
- CI Visibility: the pipeline runs the deployment events come from
- APM: the version tag that Deployment Tracking watches
- Software Delivery Accelerator: frequency and lead time views in four weeks
Four numbers that survive the question "how do you know?"
Tell us how your teams mark a hotfix. We will tell you what DORA Metrics would count today, what it would miss, and what it costs to make it true.