This product is not supported for your selected
Datadog site. (
).
Overview
DORA Metrics tracks and measures your software delivery performance using deployment events. These events power all four key DORA metrics: deployment frequency, change lead time, change failure rate, and time to restore.
To start using DORA Metrics, follow these steps:
Configure a deployment data source: Choose how you want to send deployment events to Datadog: through APM Deployment Tracking or the DORA Metrics API/CLI.
Enrich deployments with commit information: Add Git metadata (repository URL and commit SHA) to your deployment events and synchronize your repository to Datadog to enable change lead time calculations.
Customize Change Failure Detection: DORA Metrics automatically detects failed deployments through rollbacks (redeploying a previous version) and includes default rules for common rollforward patterns like revert PRs and hotfix labels. You can customize these rules to match your team’s specific workflows and remediation patterns.
When configured, deployment events automatically populate your DORA Metrics dashboard with performance data filtered by team, service, environment, and custom tags.
Limitations
- When you first select a data source option (such as APM Deployment Tracking), DORA Metrics begins populating data from that point forward. If you switch from source A to source B, then back to source A, the historical data from source A is only available from the time it was first selected.
- Deployments of the same service cannot occur at the same second.
DORA Metrics supports the following data sources for deployment events:
To send your own deployment events, use the DORA Metrics API or the datadog-ci dora deployment command.
Requirements
- datadog-ci CLI / API is enabled as a Deployments event data source in DORA settings.
- The following attributes are required:
started_at: The time the deployment started.finished_at: The time the deployment finished.service: The service that was deployed. If the provided service is registered in the Catalog with metadata set up (see Adding Metadata), the team of the service is automatically retrieved and associated with all metrics.
You can optionally add the following attributes to the deployment events:
repository_url: The source code repository of the service. Required for calculating change lead time.commit_sha: The SHA of the HEAD commit associated with the deployment. Required for calculating change lead time.team: Associate a deployment with a different team than the one found automatically for the service.env: Filter your DORA metrics by environment on the DORA Metrics page.id: Identify a deployment. This attribute is user-generated; when not provided, the endpoint returns a Datadog-generated UUID.version: The deployment version.custom_tags: Tags in the form key:value that can be used to filter events on the DORA Metrics page.
API (cURL) Example
See the DORA Metrics API reference documentation for the full spec and additional code samples.
For the following example, replace <DD_SITE> in the URL with and ${DD_API_KEY} with your Datadog API Key:
curl -X POST "https://api.<DD_SITE>/api/v2/dora/deployment" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "DD-API-KEY: ${DD_API_KEY}" \
-d @- << EOF
{
"data": {
"attributes": {
"service": "shopist",
"started_at": 1693491974000000000,
"finished_at": 1693491984000000000,
"git": {
"commit_sha": "66adc9350f2cc9b250b69abddab733dd55e1a588",
"repository_url": "https://github.com/organization/example-repository"
},
"env": "prod",
"team": "backend",
"version": "v1.12.07",
"custom_tags": ["department:engineering", "app_type:backend"]
}
}
}
EOF
CLI Example
The datadog-ci CLI tool provides a shortcut to send deployment events within your Continuous Integration environment.
For the following example, set the DD_SITE environment variable to and set the DD_API_KEY environment variable to your Datadog API Key:
export DD_SITE="<DD_SITE>"
export DD_API_KEY="<DD_API_KEY>"
export deploy_start=`date +%s`
./your-deploy-script.sh
datadog-ci dora deployment --service shopist --env prod \
--started-at $deploy_start --finished-at `date +%s` \
--version v1.12.07 --custom-tags department:engineering \
--custom-tags app_type:backend \
--git-repository-url "https://github.com/organization/example-repository" \
--git-commit-sha 66adc9350f2cc9b250b69abddab733dd55e1a588
The deployment finish time is automatically set to now if --finished-at is not provided.
If the deployment CI job is running on the exact same Git revision that is being deployed, git-repository-url and git-commit-sha can be omitted and are automatically inferred from the CI context.
The --skip-git option can be provided to disable sending the repository URL and commit SHA. When this option is added, the Change Lead Time metric becomes unavailable.
If the service associated with the deployment is registered in the Catalog with metadata set up (see Adding Metadata), the languages of the service and any tags are automatically retrieved and associated with the event.
To enable change lead time calculation, configure Git information for your deployments and synchronize your repository metadata to Datadog. This allows DORA Metrics to track how long commits take from creation to deployment.
Datadog needs access to the Git information (repository URL and commit SHA) of your deployment’s head commit SHA. The requirements differ based on your deployment data source:
For deployments identified through APM Deployment Tracking, ensure your application telemetry, in the form of traces, is tagged with Git information:
Note: For APM-tracked deployments, change lead time is calculated from commit creation to when the commit is first observed in a new version. The Deploy Time metric is not available.
For deployments tracked by the DORA Metrics API or the datadog-ci dora deployment command, ensure:
- The attributes
repository_url and commit_sha are included in the deployment events payload
Datadog needs access to your repository metadata (commits, file paths) to retrieve all commits deployed between one deployment and the previous one. Choose the synchronization method based on your Git provider:
GitHub workflows running on
pull_request trigger are not currently supported by the GitHub integration.
If you are using the
pull_request trigger, use the alternative method.
If the GitHub integration is not already installed, install it on the GitHub integration tile.
When configuring the GitHub application:
- Select at least Read repository permissions for Contents and Pull Requests.
- Subscribe at least to Push, PullRequest and PullRequestReview events.
To confirm that the setup is valid, select your GitHub application in the GitHub integration tile and verify that the Datadog Features table shows Pull Request Information meets all requirements.
If the GitLab Source Code integration is not already installed, install it on the GitLab Source Code integration tile.
Note: The scope of the service account’s personal access token needs to be at least read_api.
Handling GitLab groups and subgroups
If your repositories are organized under GitLab groups or subgroups (for example,
https://gitlab.com/my-org/group(/subgroup)/repo),
the automatic service path detection may not resolve correctly due to GitLab’s nested group structure.
To ensure that DORA metrics handle your service’s source code paths correctly,
you can use the following configuration in your service definition:
extensions:
datadoghq.com/dora-metrics:
source_patterns:
# All paths relative to the repository URL provided with the deployment
- **
# or specific paths related to this service (for monorepos)
- src/apps/shopist/**
- src/libs/utils/**
If the integration was installed before March 10, 2026, run the
webhook installation setup script again to help ensure all DORA metrics are calculated correctly. If you encounter errors, rerun the script before contacting support.
If the Azure DevOps Source Code integration is not already installed, install it on the Azure DevOps Source Code integration tile.
To set up the integration:
Open the Azure DevOps Source Code integration tile in Datadog.
Select the Configuration tab and click Connect Microsoft Entra App.
Follow the setup instructions.
Click Add Organizations.
Follow the repository installation steps and run the setup script. If the script is not run, commits made before a pull request is created will not be associated with that pull request.
After the script completes, verify the integration status on the tile. The connected repositories and projects appear in the list.
You can upload your Git repository metadata with the datadog-ci git-metadata upload command.
When this command is executed, Datadog receives the repository URL, the commit SHA of the current branch, and a list of tracked file paths.
Run this command in CI for every new commit. If a deployment is executed for a specific commit SHA, ensure that the datadog-ci git-metadata upload command is run for that commit before the deployment event is sent.
Do not provide the --no-gitsync option to the datadog-ci git-metadata upload command.
When that option is included, the commit information is not sent to Datadog and the change lead time metric is not calculated.
You can validate the correct setup of the command by checking the command output. An example of a correct output is:
Reporting commit 007f7f466e035b052415134600ea899693e7bb34 from repository git@github.com:organization/example-repository.git.
180 tracked file paths will be reported.
✅ Handled in 0.077 seconds.
Handling multiple services in the same repository
If the source code of multiple services is present in the same repository, further actions are needed to ensure that the change lead time is calculated by taking into account only the commits affecting the specific service being deployed.
To filter the commits measured to only the ones that affect the service, specify the source code glob file path patterns in the service definition.
If the service definition contains a full GitHub or GitLab URL to the application folder, a single path pattern is automatically used. The link type must be repo and the link name must be either “Source” or the name of the service (shopist in the examples below).
Example (schema version v2.2):
links:
- name: shopist
type: repo
provider: github
url: https://github.com/organization/example-repository/tree/main/src/apps/shopist
links:
- name: shopist
type: repo
provider: gitlab
url: https://gitlab.com/organization/example-repository/-/tree/main/src/apps/shopist?ref_type=heads
links:
- name: shopist
type: repo
provider: azure
url: https://dev.azure.com/organization/project/_git/example-repository?path=/src/apps/shopist
DORA Metrics for the shopist service only consider the Git commits that include changes within src/apps/shopist/**. You can configure more granular control of the filtering with extensions[datadoghq.com/dora-metrics].
Example (schema version v2.2):
extensions:
datadoghq.com/dora-metrics:
source_patterns:
- src/apps/shopist/**
- src/libs/utils/**
DORA Metrics for the service shopist only consider the Git commits that include changes within src/apps/shopist/** or src/libs/utils/**.
If the two metadata entries are defined for a service, only extensions[datadoghq.com/dora-metrics] is considered to filter the commits.
Customize Change Failure Detection
DORA Metrics automatically identifies failed deployments to calculate change failure rate and failed deployment recovery time.
How it works
Change Failure Detection operates out-of-the-box by identifying remediation deployments and linking them back to the specific deployment they are remediating.
Automatic detection (no configuration needed):
- Rollbacks: Automatically detected when a previously deployed version is redeployed.
Custom rules (customizable):
- Rollforwards: Detected through default rules that match common patterns like revert PRs and hotfix labels. You can customize these rules in the DORA settings to match your team’s specific workflows and remediation patterns.
For detailed information about how detection works and how to customize rules, see the Change Failure Detection documentation.
Further Reading
Additional helpful documentation, links, and articles: