
Datadog is a monitoring and analytics platform that teams use to watch cloud infrastructure and application performance, and to manage incidents when something breaks. Once you have a lot of monitors and dashboards, clicking through the UI to manage them stops scaling. Defining them as code with Terraform or OpenTofu fixes that.
The Datadog Terraform provider lets you define monitoring resources in the same code that provisions your infrastructure. This guide walks through how to use the provider, and then covers the integrations Scalr has with Datadog for monitoring your Terraform runs.
A few reasons to manage Datadog through the provider rather than the UI:
To start using the Datadog Terraform or OpenTofu Provider, follow these steps:
Start by configuring the Datadog Terraform provider in your Terraform code. Open your Terraform configuration file (commonly named main.tf) and add the following block:
Replace "your-datadog-api-key" with your Datadog API key and "your-datadog-app-key" with the application keys you generated earlier. The latest version of the official Datadog Terraform documentation can be found in the registry here.
Here's a simple example demonstrating how to create a basic monitor using the Datadog Terraform Provider:
In this example, we define a monitor that triggers when the 5-minute load average on a host named "host0" exceeds 2.0.
Here's a simple example demonstrating how to set downtime in Datadog using the Datadog Terraform Provider:
In this example, we'll use the datadog_monitor datasource to pull details about the monitor that was created in a previous step:
This will return details about the monitor such as the message that the monitor has set as well as the thresholds.
Once you have created your Terraform or Tofu code for the Datadog resources or datasources, you can then execute it with the following commands:
Terraform or Tofu will initialize the Datadog provider and apply the changes to your Datadog environment. Upon a successful Terraform apply, the state file will be created.
Utilize Terraform variables to make your configurations more dynamic. Instead of hardcoding values, use variables to create reusable and flexible scripts.
These variables can be defined as environment variables to make it more dynamic and avoid having secrets in the code.
For example, you can specify the following before running the Terraform init to set the Datadog API key:
export TF_VAR_api-key=<your-api-key>
Consider using remote state management to store your Terraform state files securely. Services like Scalr or AWS S3 can be configured as remote backends to store state files. Here is an example of connecting to Scalr:
Find out more about remote state management here.
That covers the basic steps to configure the Terraform Datadog provider. The provider supports a lot more than monitors and downtimes: roles, logs, and integrations with clouds like AWS. The library.tf documentation for the Terraform Datadog provider is a good place to look for those resources and more examples.
Once monitoring lives in your Terraform workflow, it gets versioned, reviewed, and rolled out the same way as the rest of your infrastructure.
Scalr, a Terraform Automation and Collaboration platform, provides a built-in integration with Datadog. Scalr is featured in the Datadog catalog, so connecting the two products is straightforward. The sections below cover what the integration sends to Datadog and how to set each part up.
The Scalr to Datadog integration for events can stream event details for Terraform and OpenTofu runs executed in Scalr. Datadog users can build reports based on the source of the run, whether it was from the Terraform CLI, a VCS provider like GitHub, or manually executed through the UI. Users can also track the result of the run, the execution time, and much more.

The events are sent through the Datadog API integration, see the official documentation here.
Scalr will send metrics to Datadog for in-depth analysis and reporting such as queued runs, queue state, the number of environments, and workspace count. These metrics are visualized in their out-of-the-box dashboard to help correlate deployments with other infrastructure changes and to track trends within your pipeline. The metrics functionality is an agent-based integration, which means you must use the Datadog agent. See how to install the Datadog agent and enable the Scalr integration here.
Scalr sends all of its audit logs to Datadog for further analysis. Audit logs allow you to get insights into all actions taken, who performed the action, how it was done, and more. The audit log feature can use the same Datadog connection that is used for events or a new one can be created.
For example, you may want to know how and when a Terraform run was discarded in the Scalr pipeline. Scalr will send the following data to Datadog:
There are two ways Datadog fits into a Terraform or OpenTofu setup. You can use the provider to manage Datadog itself, and you can use the Scalr integration to watch your Terraform and Tofu runs from inside Datadog. Most teams end up doing both.
For further reading, see our guide to monitoring Terraform runs in Datadog.
You can define entire dashboards in code. A common challenge, however, is dynamically generating widgets. The standard datadog_dashboard resource is not well-suited for this.
The solution is to use the datadog_dashboard_json resource, which accepts a JSON string. This allows you to use Terraform's for expressions to programmatically generate your widget definitions.
# variables.tf
variable "widget_configurations" {
type = map(object({
title = string
query = string
}))
default = {
"cpu_usage" = {
title = "CPU Usage",
query = "avg:system.cpu.user{*}"
},
"memory_usage" = {
title = "Memory Usage",
query = "avg:system.mem.used{*}"
}
}
}
# main.tf
resource "datadog_dashboard_json" "programmatic_dashboard" {
dashboard = jsonencode({
title = "Programmatically Generated Dashboard"
layout_type = "ordered"
widgets = [
for key, config in var.widget_configurations : {
definition = {
type = "timeseries"
title = config.title
requests = [
{
q = config.query
}
]
}
}
]
})
}SLOs are worth keeping in code so they get reviewed like anything else. This example defines a 99.9% availability SLO based on the ratio of successful API requests to total requests.
resource "datadog_service_level_objective" "api_availability" {
name = "API Request Availability"
type = "metric"
description = "99.9% of all API requests should be successful (non-5xx)."
query {
numerator = "sum:trace.http.request.hits{env:prod,service:core-api,!status_code:5xx}.as_count()"
denominator = "sum:trace.http.request.hits{env:prod,service:core-api}.as_count()"
}
thresholds {
target = 99.9
timeframe = "30d"
warning = 99.95
}
tags = ["service:core-api", "env:prod", "slo:availability"]
}As your usage grows, managing a single, monolithic Terraform configuration becomes a bottleneck. To manage Datadog at scale, consider these additional best practices:
dev, staging, prod). This provides strong isolation and prevents changes in one environment from impacting another.The following table serves as a quick reference for mapping common Datadog products to their corresponding Terraform resource types.
| Datadog Product | Primary Terraform Resource |
|---|---|
| Monitors | datadog_monitor |
| Dashboards | datadog_dashboard, datadog_dashboard_json |
| Synthetic Tests | datadog_synthetics_test |
| Service Level Objectives (SLOs) | datadog_service_level_objective |
| User Management | datadog_user |
| Role-Based Access Control | datadog_role |
| Log Indexes & Pipelines | datadog_logs_index, datadog_logs_custom_pipeline |

Terraform Datadog Provider Documentation: registry.terraform.io/providers/DataDog/datadog/latest/docs
Datadog API Documentation: docs.datadoghq.com/api/latest/
Terraform Documentation: developer.hashicorp.com/terraform/docs
Terraform Registry (Datadog Modules): registry.terraform.io/search/modules?q=datadog
Datadog Provider GitHub Repository: github.com/DataDog/terraform-provider-datadog
