Terraform Provider

Manage your Hyperping monitors, status pages, incidents, healthchecks, and maintenance windows as Terraform resources.

Maintained by Hyperping, built on the provider created by Develeap. Published on the Terraform Registry as hyperping/hyperping. Source code on GitHub.

Prerequisites

• Terraform 1.11 or later
• A Hyperping account with an API token (generate one from Settings → API, see API authentication)

Installation

1. Add the provider to your Terraform configuration

   Terraform

   Copy

   terraform {
     required_providers {
       hyperping = {
         source  = "hyperping/hyperping"
         version = "~> 2.2"
       }
     }
   }
   
   provider "hyperping" {
     api_key = var.hyperping_api_key
   }

2. Initialize your workspace

   Run terraform init to download the provider.

Supported resources

Example: create a monitor

resource "hyperping_monitor" "api" {
  name                 = "API Health Check"
  url                  = "https://api.example.com/health"
  protocol             = "http"
  check_frequency      = 60
  expected_status_code = "200"
  regions              = ["london", "virginia", "singapore"]
}

resource "hyperping_statuspage" "main" {
  name      = "Service Status"
  subdomain = "status-example"
  theme     = "dark"
}

resource "hyperping_statuspage_subscriber" "team" {
  statuspage_uuid = hyperping_statuspage.main.id
  type            = "email"
  email           = "team@example.com"
}

Example: healthchecks on a status page

Reference a healthcheck with its public_id (hc_…), directly in a section or inside a group. Uptime bars are supported; response times are not, since a healthcheck has none.

Give every service a name: it is the row label on the page, and the page does not fall back to the healthcheck or monitor name.

resource "hyperping_healthcheck" "backup" {
  name               = "Nightly backup"
  period_value       = 1
  period_type        = "days"
  grace_period_value = 1
  grace_period_type  = "hours"
}

resource "hyperping_healthcheck" "etl" {
  name               = "ETL"
  cron               = "0 */6 * * *"
  timezone           = "Europe/Berlin"
  grace_period_value = 30
  grace_period_type  = "minutes"
}

resource "hyperping_statuspage" "internal" {
  name             = "Internal status"
  hosted_subdomain = "internal-status"

  settings = {
    name      = "Internal status"
    languages = ["en"]
  }

  sections = [
    {
      name     = { en = "Scheduled jobs" }
      is_split = true
      services = [
        # A healthcheck goes by its public id (hc_), never by id (the ping token).
        {
          uuid        = hyperping_healthcheck.backup.public_id
          name        = { en = "Nightly backup" }
          show_uptime = true
        },
        # A group of services, with its own header.
        {
          is_group = true
          name     = { en = "Data pipelines" }
          services = [
            {
              uuid        = hyperping_healthcheck.etl.public_id
              name        = { en = "ETL" }
              show_uptime = true
            },
          ]
        },
      ]
    },
  ]
}

Each service of a status page also exposes a read-only type: monitor, healthcheck, server or component.

Example: SSO on a private status page

Since version 2.2.0, hyperping_statuspage_sso_connection creates an OpenID Connect connection (Auth0, Okta, Microsoft Entra ID, Keycloak…), and a status page signs its visitors in with it through settings.authentication.sso_connection_uuid. Hyperping checks the identity provider before saving, so an issuer it cannot reach or a client ID and secret it refuses fail at terraform apply and create nothing. Register the redirect_uri attribute as an allowed callback URL in your identity provider.

variable "auth0_client_secret" {
  type      = string
  sensitive = true
}

resource "hyperping_statuspage_sso_connection" "auth0" {
  name          = "Acme employees"
  issuer        = "https://acme.eu.auth0.com/"
  client_id     = "x8Qm2LkP0vZr7TnY4bWc"
  client_secret = var.auth0_client_secret

  # Only accounts with these email domains can sign in (omit for any).
  allowed_domains = ["acme.com"]
}

resource "hyperping_statuspage" "internal" {
  name             = "Internal Status"
  hosted_subdomain = "acme-internal"

  settings = {
    name      = "Internal Status"
    languages = ["en"]

    authentication = {
      sso_connection_uuid = hyperping_statuspage_sso_connection.auth0.id
    }
  }
}

# Register this URL as an allowed callback URL of the Auth0 application.
output "auth0_callback_url" {
  value = hyperping_statuspage_sso_connection.auth0.redirect_uri
}

• The client secret is write-only. The API never returns it, so a secret rotated outside Terraform is not detected: change it in the configuration and apply. After terraform import hyperping_statuspage_sso_connection.auth0 sso_…, the next apply sends it once.
• The issuer keeps your spelling (with or without https:// or a trailing slash) as long as it names the same identity provider.
• Billing. A connection is billed like one created in the dashboard, see status page SSO. Deleting a connection that a page still uses fails until the page stops using it.

SAML connections are set up in the dashboard. Link one to a page with the hyperping_statuspage_sso_connection data source, by name or id:

# A SAML connection set up in the dashboard, looked up by name.
data "hyperping_statuspage_sso_connection" "okta" {
  name = "Corporate Okta"
}

resource "hyperping_statuspage" "partners" {
  name             = "Partner Status"
  hosted_subdomain = "acme-partners"

  settings = {
    name      = "Partner Status"
    languages = ["en"]

    authentication = {
      sso_connection_uuid = data.hyperping_statuspage_sso_connection.okta.id
    }
  }
}

The resource and the data source use the SSO Connections API.

Migrating from develeap/hyperping

Version 2.1.0 of hyperping/hyperping continues develeap/hyperping 2.0.0 with the same resources and the same state format, so nothing is recreated.

1. Change the provider source

   Terraform

   Copy

   terraform {
     required_providers {
       hyperping = {
         source  = "hyperping/hyperping" # was "develeap/hyperping"
         version = "~> 2.1"
       }
     }
   }

2. Move the state and check the plan

   Shell

   Copy

   terraform state replace-provider \
     registry.terraform.io/develeap/hyperping \
     registry.terraform.io/hyperping/hyperping
   
   terraform init -upgrade
   terraform plan   # expected: No changes

   Run it once per workspace or state. The plan should show no changes. If you were still on a 1.x version of develeap/hyperping, read its 2.0.0 notes first: some secret attributes became write-only and need Terraform 1.11.

Import existing resources

You can import resources you already created in the Hyperping dashboard:

terraform import hyperping_monitor.api <monitor-id>

Find resource IDs in the Hyperping dashboard URL or via the List Monitors API.

Links

• Terraform Registry
• GitHub repository
• Changelog
• Hyperping API reference
• Terraform integration overview

Next steps