Datadog integrations-core: the officially supported checks that ship inside the Agent

The distinction that decides where your check belongs

This repository contains the open source integrations that Datadog officially develops and supports. That word officially is the whole point of the split, because there are two places a check can live, and the difference between them is who answers for it when it breaks.

The core repository, this one, is for checks Datadog develops and supports. Anything else goes to the Integrations Extras repository, with its own accompanying documentation, and the project links both from the top of the README. If you are writing a check for a product Datadog does not own, the guidance is not to contribute here anyway but to put it in extras, where the maintenance expectations are different and the support statement is different.

The second thing to understand is that these are not standalone tools. The Datadog Agent packages are equipped with all the Agent integrations from this repository, so to use them you simply install the Agent for your operating system. The check code lives in this repo, but the thing you run is the Agent, and the Agent binary is what carries your configuration.

That design has a consequence for versioning. Two files at the top of the repository track the relationship between the checks and the Agent: AGENT_CHANGELOG.md shows which integrations have been updated in each Agent version, and AGENT_INTEGRATIONS.md is the companion listing. So when you are chasing a behaviour change in a check, the Agent changelog is where you find out which Agent version carries it.

One directory per check, each with its own dependency set

The repository layout is the fastest way to understand the model. The top level is a flat list of integration directories, one per check, and the names make the scope obvious: activemq, activemq_xml, adyen, aerospike, agent_metrics, airbyte, airflow, amazon_app_mesh, amazon_eks, amazon_eks_blueprints, amazon_msk, ambari, anomali_threatstream, anthropic, anthropic_compliance_logs, anthropic_usage_and_costs, anyscale, apache, appgate_sdp, arangodb, arctic_wolf_aurora_endpoint_security, argo_rollouts, argo_workflows, argocd, asana, aspdotnet, authorize_net, avast, avi_vantage, aws_neuron, azure_active_directory, and the list continues well past that in the directory listing.

Each of those directories is a self-contained Python package with its own requirements, its own configuration models and its own tests. That is what makes the whole thing buildable in parallel and what allows the Agent to package only the checks a given user enables.

The tooling reflects that granularity. There is a .ddev directory holding the configuration for the ddev tool, .deps for dependency handling, .builders for packaging, .stubs for type stubs, .evalya for schema evaluation, .devcontainer for a local development container, and a .codespell directory for the spell checker exclusions. There are also several CI surfaces rather than one: a .github directory for the GitHub Actions workflows, and separately .gitlab-ci.yml and a .gitlab directory, which tells you the project is built in two CI systems.

The in-toto directory is there for supply chain attestation of the build, and the .pre-commit-config.yaml runs the same checks before a commit reaches CI.

Mypy and Ruff settings that reveal what the code is allowed to be

The typing and lint configuration in pyproject.toml says more about the code base than any amount of documentation, so it is worth reading in detail.

For Mypy, the plugin is pydantic.mypy, which is what makes the Pydantic configuration models type-check properly. follow_imports is set to normal, and ignore_missing_imports is true so that third-party packages without type hints do not produce noise. disallow_untyped_defs is explicitly false, and the comment explains why: requiring every function to be annotated would create a lot of noise for imported modules that are not annotated yet, and the config makes that choice explicit rather than leaving it as an accident of the default.

The mypy_path is set to ../.stubs relative to the integration folder, which is how the shared stub packages get picked up. Generated files are excluded by pattern, covering config_models and the ddev create templates. python_version is pinned to 3.13, and the ruff target-version is py313 as well, so the project targets a current Python and says so.

Ruff runs with a line length of 120 and namespace-packages set to datadog_checks, which is what allows the checks to share a namespace without packaging gymnastics:

[tool.ruff]
target-version = "py313"
line-length = 120
namespace-packages = ["datadog_checks"]

[tool.ruff.lint]
select = ["B", "C", "E", "F", "G", "W", "I", "TID252"]

The rule selection is listed as B, C, E, F, G, W, I and TID252, with a comment that the rules were ported over from the legacy flake8 settings for parity, and the ignore list carries over the legacy flake8 exclusions. The exclude list is the interesting part: autogenerated files from ddev validate models are skipped, along with vendored directories inside checks and the ddev tooling templates, because formatting generated code creates diff noise that hides real changes.

ddev is the build, test and scaffolding tool for a check

The development tool for this repository is ddev, and the release tags in this project are ddev releases, with ddev-v20.1.0 published on 2026-10-15, ddev-v20.0.0 on 2026-09-30 and ddev-v19.1.0 on 2026-09-18. The ddev version therefore moves with its own release train, independently of the Agent versions that ship the checks.

The documentation describes the workflow as getting a dev environment up and running in minutes to run, test and build a check, and the configuration is at .ddev. The ddev tool also generates the templated files, and the ruff exclusion list confirms that: the ddev create templates and the ddev validate output under config_models are all excluded from linting and formatting because they are generated. That is a fairly advanced level of tooling, and it explains why the mypy and ruff configs need to know which files are generated.

The project also carries a LICENSE-3rdparty.csv, which is a list of the third-party licences covering the vendored and depended-on code inside the checks, alongside the repository's own LICENSE. The licence for the project itself is BSD-3-Clause, and the badge row in the README links the SPDX identifier. A repository that vendors code from many vendors and ships a third-party licence manifest is doing the compliance work that a Datadog customer inherits when they run the Agent.

For contributors, the docs point to the development documentation for the main path and to the more advanced documentation at datadoghq.dev for the deeper material, with a contribution guide, a code of conduct and a set of issue templates for reporting problems.

Getting a dev environment up and running for a check

The README is honest that it does not contain an install command, and that is not an oversight. This repository is not installed by end users; it is consumed through the Agent, and the developer path is documented separately. The guidance is to follow the development docs to get a dev environment running in minutes so you can run, test and build a check, with the more advanced documentation linked for everything beyond that.

What the repository itself gives you is the environment scaffolding. There is a .devcontainer directory, so the dev container definition travels with the code and a checkout is enough to get a consistent environment. There is a .ddev directory holding the ddev configuration, which is the tool that runs, tests and builds a check and that generates the templated files. There is a .deps directory for dependency handling, and agent_requirements.in at the top level for the Agent-wide dependency set.

The test tooling is pytest, referenced from the documentation links, and the mypy configuration notes that its path is relative to the tox execution path, which tells you the type check runs under tox rather than directly against a virtualenv. The pre-commit configuration at the top level runs the same linting and formatting before a commit, and the .codespell directory holds the exclusion list for the spell checker.

So the sequence for a new contributor is: install ddev, open the project in the dev container, use ddev to run and test the check you are working on, and let pre-commit and the CI workflows catch the rest.

What this repository is not

The first limitation is that it is not a place to publish an unsupported check. The project explicitly redirects new integrations that Datadog does not officially develop to the Integrations Extras repository, and offers its own documentation for that path. The AGENT_CHANGELOG.md file only tracks what happens to the officially supported set, so a check in extras will not appear there.

The second limitation is that the Agent is the delivery vehicle. You cannot take a check from this repository and run it standalone in your own process the way you might with a small library, because the code is written to be packaged into the Agent and configured through the Agent's configuration. If your requirement is a metric emitted by a small process you control, this is the wrong shape, and the requirements-integration-core and requirements-agent-release files referenced from the README are the place to check what each check actually pulls in.

The third limitation is the one that comes with the size of the tree. This is a monorepo with hundreds of integration directories, each with its own dependency pins, and the dependency management is handled at the.deps level with the agent_requirements.in file at the top. The upside is a single place where a check is fixed for all Agent users. The downside is that a change in one check's dependencies can ripple into the Agent build, and the pin lines in those two requirements files are the place where that shows up.

On maintenance, the repository is not archived, the last push was on 2026-10-19, and releases have been frequent through the year with ddev-v20.1.0, ddev-v20.0.0 and ddev-v19.1.0 in the last month.

Editorial conclusion

integrations-core is the right place to work if you want a check that Datadog maintains and ships inside the Agent, and it is the right place to start if you are about to write an integration and want to see the house conventions for dependency pinning, configuration models and testing. It is a poor fit if you want a community-maintained check, since the project directs those to the separate Integrations Extras repository, and a poor fit if you want to run a check outside the Agent, since these packages are built to be packaged with the Agent. Before contributing, read the development docs, install the ddev tooling, and check AGENT_CHANGELOG.md to see which checks moved in the Agent version you are targeting.

Frequently asked questions

Official sources

1. DataDog/integrations-core on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases