Understanding Monitoring as Code

The traditional approach (and its problems)

Traditionally, monitoring is configured through web dashboards:

1. Log into a web interface
2. Click through forms to create monitors
3. Manually replicate configuration across environments
4. No audit trail of who changed what
5. Difficult to review changes before they go live

This works for small teams with few monitors, but doesn't scale.

What is monitoring as code?

Monitoring as Code treats your monitoring configuration the same way you treat your application code: as text files that can be versioned, reviewed, and deployed through automated pipelines.

Instead of clicking buttons, you declare monitors, status pages, and notifications in Terraform — and apply them with the same workflow your team already uses for the rest of your infrastructure.

Why use monitoring as code?

This approach offers significant advantages:

• Version control — every change to a monitor lives in Git. You can see who modified what, review diffs, and roll back to a known-good state. Crucial for auditing and troubleshooting.
• Automation and consistency — your monitoring setup becomes part of your deployment pipeline. When you ship a new service, its monitors, alerts, and status page components are provisioned automatically alongside it — no risk of forgetting to wire one up.
• Collaboration — a code-based workflow makes peer review natural. A developer opens a pull request that adds a monitor, the team reviews it like any other change, and terraform plan shows exactly what will happen before it does.
• Scalability — managing hundreds of monitors through a UI is impractical. With Terraform, you can use modules, for_each, and variables to generate configurations programmatically as your infrastructure grows.
• Simplified auditing — the current state of every monitor, page, and notification is captured in your .tf files. One terraform plan shows you any drift between what's declared and what's live.

How it works with openstatus

We publish an official Terraform provider that lets you manage your entire openstatus workspace declaratively — monitors, status pages, component groups, notifications, and maintenance windows.

Here's what a minimal main.tf looks like:

terraform {
  required_providers {
    openstatus = {
      source  = "openstatusHQ/openstatus"
      version = "~> 0.1"
    }
  }
}

provider "openstatus" {
  api_token = var.openstatus_api_token
}

resource "openstatus_http_monitor" "api" {
  name        = "API Health Check"
  description = "Monitors the main API health endpoint."
  url         = "https://api.example.com/health"
  periodicity = "5m"
  method      = "GET"
  active      = true
  regions     = ["fly-iad", "fly-ams", "fly-syd"]

  status_code_assertions {
    target     = 200
    comparator = "eq"
  }

  body_assertions {
    target     = "ok"
    comparator = "contains"
  }
}

resource "openstatus_notification" "slack" {
  name          = "Slack Alerts"
  provider_type = "slack"
  monitor_ids   = [openstatus_http_monitor.api.id]

  slack {
    webhook_url = var.slack_webhook_url
  }
}

Applying changes

Once your configuration is ready, the standard Terraform workflow takes over. terraform plan shows you a diff against the live state; terraform apply reconciles it.

terraform init    # Download the openstatus provider
terraform plan    # Preview what will change
terraform apply   # Apply the changes

Terraform only modifies what changed — updates are in place, with no downtime for unaffected monitors.

Adopting it for an existing workspace

If you already have monitors and status pages set up in the dashboard, you don't have to rewrite them by hand. The openstatus CLI can export your workspace into ready-to-use .tf files:

openstatus terraform generate

From there, import the resources into Terraform state and you're managing the existing setup as code.

Best practices

1. Start simple — begin with a few monitors, expand as you learn.
2. Use modules — wrap common monitor patterns in reusable Terraform modules.
3. Sensitive variables — mark API tokens and webhook URLs as sensitive and pass them via TF_VAR_* env vars or a secrets manager.
4. Review changes — always run terraform plan and review the diff before applying.
5. Document decisions — use commit messages to explain "why".

Next steps

• Manage openstatus with Terraform — end-to-end guide.
• Terraform provider reference — full resource specification.
• Monitor your MCP server — real-world example.