Then, configure the integration on a project by going to Settings > Integrations > Datadog for each project you want to instrument.
Note: Due to a bug in early versions of GitLab, the Datadog integration cannot be enabled at group or instance level on GitLab versions < 14.1, even if the option is available on GitLab's UI
Fill in the integration configuration settings:
Enables the integration.
Specifies which Datadog site to send data to. Default: datadoghq.com Selected site:
API URL (optional)
Allows overriding the API URL used for sending data directly, only used in advanced scenarios. Default: (empty, no override)
Specifies which API key to use when sending data. You can generate one in the APIs tab of the Integrations section on Datadog.
Specifies which service name to attach to each span generated by the integration. Use this to differentiate between GitLab instances. Default: gitlab-ci
Specifies which environment (env tag) to attach to each span generated by the integration. Use this to differentiate between groups of GitLab instances (for example: staging or production). Default: none
Specifies any custom tags to attach to each span generated by the integration. Provide one tag per line in the format: key:value. Default: (empty, no additional tags) Note: Available only in GitLab.com and GitLab >= 14.8 self-hosted.
You can test the integration with the Test settings button (only available when configuring the integration on a project). After it’s successful, click Save changes to finish the integration set up.
Integrate through webhooks
As an alternative to using the native Datadog integration, you can use webhooks to send pipeline data to Datadog.
Note: The native Datadog integration is the recommended approach and the option that is actively under development.
Go to Settings > Webhooks in your repository (or GitLab instance settings), and add a new webhook:
URL: https://webhook-intake./api/v2/webhook/?dd-api-key=<API_KEY> where <API_KEY> is your Datadog API key.
Secret Token: leave blank
Trigger: Select Job events and Pipeline events.
To set custom env or service parameters, add more query parameters in the webhooks URL: &env=<YOUR_ENV>&service=<YOUR_SERVICE_NAME>
Set custom tags
To set custom tags to all the pipeline and job spans generated by the integration, add to the URL a URL-encoded query parameter tags, with key:value pairs separated by commas. If a key:value pair contains any commas, surround it with quotes. For example, to add key1:value1,"key2: value with , comma",key3:value3, the following string would need to be appended to the Webhook URL:
After the integration is successfully configured, the Pipelines and Pipeline Executions pages populate with data after the pipelines finish.
Note: The Pipelines page shows data for only the default branch of each repository.
Partial and downstream pipelines
In the Pipeline Executions page, you can use the filters below in the search bar:
Possible values: true, false
Possible values: true, false
Possible values: retry, paused, resumed
These filters can also be applied through the facet panel on the left hand side of the page.
Correlate infrastructure metrics to jobs
If you are using self-hosted GitLab runners, you can correlate jobs with the infrastructure that is running them.
For this feature to work, the GitLab runner must have a tag of the form host:<hostname>. Tags can be added while
registering a new runner. For existing runners, add tags by updating the runner’s config.toml. Or add tags
through the UI by going to Settings > CI/CD > Runners and editing the appropriate runner.
After these steps, CI Visibility adds the hostname to each job. To see the metrics, click on a job span in the trace
view. In the drawer, a new tab named Infrastructure appears which contains the host metrics.
View error messages for pipeline failures
Error messages are supported for GitLab versions 15.2.0 and above.
For failed GitLab pipeline executions, each error under the Errors tab within a specific pipeline execution displays a message associated with the error type from GitLab.
See the table below for the message and domain correlated with each error type. Any unlisted error type will lead to the error message of Job failed and error domain of unknown.
Failed due to unknown reason
Failed due to error on CI/CD configuration file
Failed due to external pipeline validation
The pipeline failed due to the user not being verified
The pipeline activity limit was exceeded
The pipeline size limit was exceeded
The pipeline job activity limit was exceeded
The pipeline deployments limit was exceeded
The project associated with this pipeline was deleted
Pipeline is stuck or timed out
Failed due to runner system failure
Failed due to missing dependency
Failed due to unsupported runner
Failed due to stale schedule
Failed due to job timeout
Failed due to unmet prerequisite
Failed due to schedule failure
Failed due to data integrity
Blocked by user
CI quota exceeded
Pipeline loop detected
Secret provider not found
Reached max descendant pipelines
IP restriction failure
Enable job log collection (beta)
The following GitLab versions support collecting job logs: