terraform {
required_providers {
hyperping = {
source = "develeap/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 built by Develeap, who run it in production at scale. Read the launch story.