terraform {
required_providers {
hyperping = {
source = "hyperping/hyperping"
}
}
}
provider "hyperping" {
api_key = var.hyperping_api_key
}
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"
}terraform init && terraform apply — your monitoring is live.
Clicking through a dashboard works for 10 monitors. It breaks at 50: no audit trail, no staging/production parity, and drift between what you think is monitored and what actually is.
With the Hyperping provider, onboarding a new service is a Terraform module. Changes go through pull requests. Rollbacks are a terraform apply away. And because the provider ships migration tooling for Better Stack, UptimeRobot, and Pingdom, switching to Hyperping is a code review — not a copy-paste marathon.
The provider is open source, published on the Terraform Registry and maintained by Hyperping. It was created by Develeap, who run it in production at scale. Read the launch story.