---
title: "Terraform Provider for Uptime Monitoring and Status Pages"
url: "https://www.openstatus.dev/tooling/terraform"
date: "2026-04-29"
updated: "2026-09-27"
author: "Maximilian Kaske"
description: "Manage monitors, notifications and status pages as HCL with the openstatus Terraform provider. Same plan-and-apply lifecycle, one command to bootstrap."
category: "Product"
---

The [openstatus Terraform provider](https://registry.terraform.io/providers/openstatusHQ/openstatus/latest) treats monitoring as code: monitors, notifications, and status pages live in the same plan-and-apply lifecycle as the rest of your infrastructure.

## Quickstart

```hcl
terraform {
  required_providers {
    openstatus = {
      source = "openstatusHQ/openstatus"
    }
  }
}

resource "openstatus_http_monitor" "api" {
  name        = "API"
  url         = "https://api.example.com/health"
  periodicity = "1m"
  regions     = ["fly-iad", "fly-ams", "fly-syd"]
}
```

```bash
export OPENSTATUS_API_TOKEN=os_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
terraform init
terraform plan
terraform apply
```

## What you can do

- Manage every primary entity — monitors, notification channels, status pages, subscribers, maintenance windows — through HCL.
- Roll changes out alongside the rest of your infrastructure (Vercel projects, DNS records, secrets).
- Bootstrap an HCL file from your existing workspace with `openstatus terraform generate` — no hand-writing required.
- Code-review monitor changes in the same PR that adds the service being monitored.

## Bootstrap from an existing workspace

If you already have monitors and status pages in the dashboard, the CLI generates HCL for you:

```bash
openstatus terraform generate
```

The output is a valid HCL configuration with cross-references between resources and `import` blocks pre-wired so `terraform plan` shows zero drift on first run.

## Auth & audit

Set `OPENSTATUS_API_TOKEN` before running Terraform. The token is the same one the CLI, API, and MCP server share — generate it from **Settings > General > API Keys**.

Every mutation through the provider lands in the audit log under `actor_type = 'apiKey'` with the key that made it, so you can trace any change back to a key and the user who created it. Give Terraform its own key to keep its changes separable from other API callers.

## Other surfaces

- Prefer a YAML config in your repo? See the [CLI](/tooling/cli) and `openstatus monitors apply`.
- Building an in-app integration? Call the [API](/tooling/api) directly.
- Want Claude or ChatGPT to read or update status reports? See the [MCP server](/tooling/mcp-server).

## Reference

Full resource list and schema in the [Terraform reference](/docs/reference/terraform).

## Frequently asked questions

<details>
  <summary>How does the Terraform provider compare to the CLI?</summary>
  The Terraform provider is the right choice if monitoring is part of a larger HCL-managed infrastructure. The CLI's YAML config is lighter to adopt and ships with openstatus terraform generate to bootstrap an HCL file from your existing workspace if you want to migrate.
</details>

<details>
  <summary>What resources does the provider expose?</summary>
  Monitors, notification channels, status pages, status page subscribers, and maintenance windows — every primary entity in the dashboard. See the Terraform reference for the full list and schema.
</details>

<details>
  <summary>How do I migrate an existing workspace into Terraform?</summary>
  Run openstatus terraform generate from the CLI. It fetches your full configuration and produces valid HCL with cross-references and import blocks — no hand-writing required.
</details>

<details>
  <summary>Where do I get an API token?</summary>
  Generate one from Settings > General > API Keys, then set `OPENSTATUS_API_TOKEN` before running terraform plan. The same token works across the CLI, API, and MCP server.
</details>