Skip to content

What do you need to do?

Docs

Terraform provider

Manage checks, status pages, status page components and notification channels as code. The realuptime provider is a thin, hand-mapped layer over the REST API: every attribute is an API field under its own name, so what you write in HCL is what the API receives.

On this page

Availability

Live on the Terraform Registry. The provider is published at registry.terraform.io/providers/RealUptimeHQ/realuptime, version 0.1.0, community tier. Its source is public at github.com/RealUptimeHQ/terraform-provider-realuptime and builds with a stock Go toolchain if you would rather build it yourself, but terraform init downloads it directly today; no dev override is needed.

Requirements

Terraform 1.5 or newer, and a RealUptime API key with read_write permission, on any plan, exported as REALUPTIME_API_KEY. A read-only key can plan but every create, update and destroy is refused with RU-1004. Generate the key from the dashboard's API & MCP access section; it is shown once. REALUPTIME_API_URL (or the provider's base_url) points the provider at a different API root; you only need it for a local development server.

Provider block

terraform
terraform {
  required_providers {
    realuptime = {
      source  = "RealUptimeHQ/realuptime"
      version = "~> 0.1"
    }
  }
}

# Reads REALUPTIME_API_KEY. Pass api_key only from a secret store, never a literal.
provider "realuptime" {}

Resources

Four resources and one data source, each mapped to one API route family. Attribute-by-attribute reference lives in the provider repository's docs/ folder (generated from the schemas, so it cannot drift from the code).

  • realuptime_check: an http monitor (POST /checks). regions and the response assertions update in place; name, url and interval_seconds are set at creation (the API has no edit route for them), so changing one replaces the check and its history. Other monitor types are created from the dashboard and can be imported.
  • realuptime_status_page: an additional status page with its brand chrome (title, description, logo, accent, theme, font, locale, links). Free includes one page; the account's last page cannot be destroyed.
  • realuptime_status_page_component: publishes a check on a page. Destroying it unpublishes the check; the check keeps running. Agent-bound monitors are refused: they are private by design.
  • realuptime_notification_channel: Discord, Microsoft Teams, Opsgenie or a generic JSON endpoint in the channel registry. The credential is write-only: the API never returns it, and responses carry a redacted summary instead.
  • data.realuptime_status_page: look a page up by id or slug, typically the page created at signup.

Examples

terraform
resource "realuptime_check" "api" {
  name             = "Public API"
  url              = "https://api.example.com/health"
  interval_seconds = 60
  regions          = ["iad", "fra"]

  assertion_status_min = 200
  assertion_status_max = 299
  assertion_body_op    = "contains"
  assertion_body_value = "ok"
}
terraform
data "realuptime_status_page" "main" {
  slug = "acme" # the page created at signup
}

resource "realuptime_status_page_component" "api" {
  status_page_id = data.realuptime_status_page.main.id
  check_id       = realuptime_check.api.id
  display_name   = "API"
  description    = "REST API and webhooks"
}

resource "realuptime_status_page" "internal" {
  name         = "Acme internal"
  slug         = "acme-internal"
  theme_preset = "slate"
  accent_color = "#1f6feb"
}
terraform
resource "realuptime_notification_channel" "discord" {
  type = "discord"
  name = "Ops Discord"
  config = {
    webhookUrl = var.discord_webhook_url # write-only: never read back
  }
}

Installing

With the provider block above in your configuration, initialize and plan the ordinary way:

bash
terraform init
terraform plan

Set this up with your AI assistant

Paste this into Claude Code, Cursor, Codex or any AI coding assistant with access to your project, and it can write the configuration and run init/plan itself.

text
Set up the RealUptime Terraform provider in my project.

1. Add this to my Terraform configuration:

terraform {
  required_providers {
    realuptime = {
      source  = "RealUptimeHQ/realuptime"
      version = "~> 0.1"
    }
  }
}

# Reads REALUPTIME_API_KEY. Pass api_key only from a secret store, never a literal.
provider "realuptime" {}

2. Export REALUPTIME_API_KEY from a secret store (never a literal in the
   config) with read_write permission, generated from the dashboard's
   API & MCP access section (it is shown once).
3. Add a realuptime_check resource for the endpoint I want monitored, e.g.:

resource "realuptime_check" "api" {
  name             = "Public API"
  url              = "https://api.example.com/health"
  interval_seconds = 60
  regions          = ["iad", "fra"]

  assertion_status_min = 200
  assertion_status_max = 299
  assertion_body_op    = "contains"
  assertion_body_value = "ok"
}

4. Run terraform init, then terraform plan, and show me the plan before
   applying it.

Docs: https://docs.realuptime.io/terraform

Importing what you already have

bash
terraform import realuptime_check.api <check id>
terraform import realuptime_status_page.main <status page id>
terraform import realuptime_status_page_component.api <status page id>/<component id>
terraform import realuptime_notification_channel.discord <channel id>

A notification channel's credential cannot be read back, so the first plan after importing one shows config being set from your configuration: one in-place update, which also clears the channel's verified flag until the next successful test send.

Rate limits and errors

The provider uses the same per-key write budget as any other API client (see Rate limits). A large first apply can hit it; the provider honors Retry-After once and then surfaces the error, so lower -parallelism rather than retrying blindly. Every refusal carries its stable RU- code and a link to the matching error page.

Honesty notes

Nothing here fabricates state. A check created by Terraform reports unknown until its first probe lands, a new channel is unverified until a test send succeeds, and an attribute the API does not expose (custom domains, passwords, component ordering, alert-rule attachments) is read-only or absent in the provider rather than pretended.