---
title: Code Coverage Configuration
description: Configure code coverage behavior with a configuration file in your repository.
breadcrumbs: Docs > Code Coverage > Code Coverage Configuration
---

# Code Coverage Configuration

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ().
{% /alert %}

{% /callout %}

## Overview{% #overview %}

You can configure Code Coverage behavior by creating a configuration file named `code-coverage.datadog.yml` or `code-coverage.datadog.yaml` in the root of your repository.

Example configuration file:

```yaml
schema-version: v1
services:
  - id: frontend
    paths:
      - frontend/
      - shared/ui/**
  - id: backend-api
    paths:
      - backend/api/**
      - backend/.*\.go
ignore:
  - "test/**/*"
  - "**/*.pb.go"
gates:
  - type: total_coverage_percentage
    config:
      threshold: 85
  - type: patch_coverage_percentage
    config:
      threshold: 95
```

## Services configuration{% #services-configuration %}

{% alert level="info" %}
Using [Software Catalog integration](https://docs.datadoghq.com/code_coverage/monorepo_support.md#software-catalog-integration) is the recommended approach for defining services, as code locations configured in Software Catalog can be used by multiple Datadog products. Use manual configuration only when Software Catalog integration is not available.
{% /alert %}

You can define services in your configuration file to split coverage data by service in monorepos. This is useful when multiple projects or teams share a single repository and you want to view coverage metrics for each service independently.

```yaml
schema-version: v1
services:
  - id: frontend
    paths:
      - frontend/**
      - shared/ui/**
  - id: backend-api
    paths:
      - backend/api/**
```

- `schema-version` (required): Must be `v1`
- `services`: List of service definitions
  - `id` (required): Unique identifier for the service
  - `paths` (required): List of path patterns that belong to this service (see Pattern syntax)

For complete details on monorepo support, including Software Catalog integration and code owner-based splitting, see [Monorepo Support](https://docs.datadoghq.com/code_coverage/monorepo_support.md).

### Examples{% #examples %}

{% collapsible-section %}
#### JavaScript/TypeScript monorepo

In the `code-coverage.datadog.yml` file:

```yaml
schema-version: v1
services:
  - id: web-app
    paths:
      - packages/web/**
      - packages/shared/ui/**
  - id: mobile-app
    paths:
      - packages/mobile/**
      - packages/shared/core/**
  - id: admin-dashboard
    paths:
      - packages/admin/**
```

{% /collapsible-section %}

{% collapsible-section %}
#### Multi-language monorepo

In the `code-coverage.datadog.yml` file:

```yaml
schema-version: v1
services:
  - id: backend-service
    paths:
      - services/backend/**
      - services/backend/.*\.go
  - id: frontend-web
    paths:
      - services/frontend/**
      - services/frontend/.*\.(ts|tsx)
  - id: data-processing
    paths:
      - services/data/**
      - scripts/.*\.py
```

{% /collapsible-section %}

## Ignoring paths{% #ignoring-paths %}

You can exclude specific files or directories from code coverage reporting using the `ignore` field. This is useful for excluding test files, generated code, vendor dependencies, and other files that should not be included in coverage metrics. Path patterns support glob, regex, and prefix matching (see Pattern syntax).

```yaml
ignore:
  - "test/**/*"           # Exclude all files in test directory
  - "*.pb.go"             # Exclude all protobuf generated files
  - "vendor/"             # Exclude vendor directory
```

### Exceptions{% #exceptions %}

Add `!` before a pattern to create an exception to your ignore rules. This lets you include specific files or folders that would otherwise be excluded.

```yaml
ignore:
  - "generated/"          # Ignore all generated code
  - "!generated/core/"    # Except core generated files
```

**Important**: Negative patterns take precedence over positive patterns. If any negative pattern matches a file path, that path is *not* ignored.

### Examples{% #examples-1 %}

{% collapsible-section %}
#### Exclude test files and generated code

```yaml
ignore:
  - "**/*_test.go"        # Exclude Go test files
  - "**/*.pb.go"          # Exclude protobuf files
  - "vendor/"             # Exclude vendor directory
  - "mocks/"              # Exclude mock files
```

{% /collapsible-section %}

{% collapsible-section %}
#### Exclude with exceptions

```yaml
ignore:
  - "generated/"          # Ignore all generated code
  - "!generated/core/"    # Except core generated files
  - "test/"               # Ignore test directory
  - "!test/integration/"  # Except integration tests
```

{% /collapsible-section %}

{% collapsible-section %}
#### Mixed pattern types

```yaml
ignore:
  - "^vendor/.*"          # Regex: exclude vendor (anchored)
  - "**/*.min.js"         # Glob: exclude minified JS files
  - "dist/"               # Prefix: exclude dist directory
  - ".*\\.pb\\.go$"       # Regex: exclude protobuf files
```

{% /collapsible-section %}

## PR Gates{% #pr-gates %}

You can define [PR Gates](https://app.datadoghq.com/ci/pr-gates/rule/create?dataSource=code_coverage) in the configuration file to enforce code coverage thresholds on pull requests. If gates are also configured in the [Datadog UI](https://app.datadoghq.com/ci/pr-gates/rule/create?dataSource=code_coverage), Datadog evaluates both the configuration file rules and the UI rules when a PR is opened or updated.

{% alert level="info" %}
If both the configuration file and the Datadog UI define gates for the same scope, the pull request must meet every defined threshold.
{% /alert %}

```yaml
gates:
  - type: total_coverage_percentage
    config:
      threshold: 85

  - type: patch_coverage_percentage
    config:
      threshold: 95
```

Each gate has the following fields:

- `type` (required): The type of coverage gate. Supported values:
  - `total_coverage_percentage`: The minimum overall coverage percentage for the repository (or for the scoped services or code owners).
  - `patch_coverage_percentage`: The minimum coverage percentage on code changed in the pull request.
- `config` (required): Gate configuration options. Supported values:
  - `threshold` (required): The minimum coverage percentage (0-100).
  - `services`: (optional) A list of service name patterns to scope the gate to. Use `*` as a wildcard. Prefix a value with `!` to exclude matching services. When set, coverage is evaluated separately for each matching service.
  - `codeowners`: (optional) A list of code owner patterns to scope the gate to. Use `*` as a wildcard. Prefix a value with `!` to exclude matching code owners. When set, coverage is evaluated separately for each matching code owner.
  - `flags`: (optional) A list of [flag](https://docs.datadoghq.com/code_coverage/flags.md) name patterns to scope the gate to. Use `*` as a wildcard. Prefix a value with `!` to exclude matching flags. When set, coverage is evaluated separately for each matching flag.

### Examples{% #examples-2 %}

{% collapsible-section %}
#### Unscoped total and patch coverage gates

In the `code-coverage.datadog.yml` file:

```yaml
schema-version: v1
gates:
  - type: total_coverage_percentage
    config:
      threshold: 80

  - type: patch_coverage_percentage
    config:
      threshold: 90
```

{% /collapsible-section %}

{% collapsible-section %}
#### Gates scoped to services

In the `code-coverage.datadog.yml` file:

```yaml
schema-version: v1
services:
  - id: backend-api
    paths:
      - backend/api/**
  - id: frontend-web
    paths:
      - frontend/**
gates:
  - type: patch_coverage_percentage
    config:
      threshold: 90
      services:
        - "*"

  - type: total_coverage_percentage
    config:
      threshold: 85
      services:
        - "backend-api"
```

{% /collapsible-section %}

{% collapsible-section %}
#### Gates scoped to code owners

In the `code-coverage.datadog.yml` file:

```yaml
schema-version: v1
gates:
  - type: patch_coverage_percentage
    config:
      threshold: 95
      codeowners:
        - "@DataDog/backend-team"
        - "@DataDog/api-*"

  - type: total_coverage_percentage
    config:
      threshold: 80
      codeowners:
        - "@DataDog/frontend-team"
```

{% /collapsible-section %}

{% collapsible-section %}
#### Gates scoped to flags

In the `code-coverage.datadog.yml` file:

```yaml
schema-version: v1
gates:
  - type: total_coverage_percentage
    config:
      threshold: 80
      flags:
        - "unit-tests"

  - type: patch_coverage_percentage
    config:
      threshold: 90
      flags:
        - "integration-tests"
```

{% /collapsible-section %}

{% collapsible-section %}
#### Excluding with negation

Use the `!` prefix to exclude specific services, code owners, or flags from a gate. For example, to enforce coverage on all services except experimental ones, and on all flags except nightly tests:

In the `code-coverage.datadog.yml` file:

```yaml
schema-version: v1
gates:
  - type: total_coverage_percentage
    config:
      threshold: 80
      services:
        - "*"
        - "!experimental-*"

  - type: patch_coverage_percentage
    config:
      threshold: 90
      flags:
        - "*"
        - "!nightly-*"
```

{% /collapsible-section %}

## Pattern syntax{% #pattern-syntax %}

Configuration options that accept file paths support three types of patterns:

- `regex`
- `glob`
- `path_prefix`

The pattern type is automatically detected based on the syntax you use.

### Regex patterns{% #regex-patterns %}

Patterns containing regex-specific characters (`+`, `{`, `}`, `|`, `(`, `)`, `^`, `$`, `\`) are treated as regular expressions:

- `".*\\.pb\\.go$"` - Matches files ending with `.pb.go`
- `"^generated/.*"` - Matches files in the generated directory
- `".*_test\\.go$"` - Matches test files

**Note**: Regex patterns are automatically anchored with `^...$` for whole-path matching. Use forward slashes (`/`) as path separators in regex patterns.

### Glob patterns{% #glob-patterns %}

Patterns containing glob-specific characters (`*`, `?`, `[`, `]`) are treated as glob patterns:

- `"**/*.java"` - Matches all Java files
- `"src/test/**/*"` - Matches all files under src/test
- `"*.pb.go"` - Matches protobuf files in any directory

**Note**: Use `**` to match directories recursively. The pattern `folder/*` matches only direct children, while `folder/**/*` matches all descendants.

### Prefix patterns{% #prefix-patterns %}

Simple path prefixes without special characters are treated as prefix matches:

- `"vendor/"` - Matches all files under vendor directory
- `"third_party/"` - Matches third-party code
- `"generated/"` - Matches generated code

## Further reading{% #further-reading %}

- [Code Coverage](https://docs.datadoghq.com/code_coverage.md)
- [Set up Code Coverage](https://docs.datadoghq.com/code_coverage/setup.md)
- [Organize coverage data with flags](https://docs.datadoghq.com/code_coverage/flags.md)