infrastructure as code
Uptime monitoring you declare in Terraform
Provision a monitor the same way you provision the service it watches. The Uptimepage provider manages monitors, status pages, components and notification channels in HCL, so every new service ships with monitoring instead of a follow-up ticket.
Monitoring ships with the service
Declare the monitor next to the resource it watches, in the same repository and the same apply. Every new service gets a check from the moment it exists, instead of a follow-up ticket someone closes three sprints later. And when you stand up a new region, you reproduce forty monitors with one apply instead of forty afternoons of clicking.
Review it like any other change
Open any monitoring dashboard and count the checks nobody can explain. The one with the 47-second interval: why 47? The two still pointed at a staging box decommissioned in March. Click-created config rots, because the reasoning leaves with its author. In a repo, every change is a pull request: "why are we dropping the interval on the payments check?" is a better conversation to have in review than in a postmortem, and git blame remembers the answer after the author moves on.
A schema that refuses nonsense
The provider’s check block is nested on purpose: you set the type to "http" and then fill in an http block. A flat resource with url, port, host and cert_days all at the top level would let you write a TCP check with an HTTP status matcher and only tell you at apply time. The nested shape makes those invalid states impossible to write. A little more verbose, and a whole category of mistake is gone.
Once it is in code, the code wins
There is a trade, and it is worth knowing up front: once a monitor is in Terraform, the dashboard stops being the source of truth. Bump an interval by hand and the next plan proposes to revert it; run terraform plan -refresh-only to see drift before it surprises you. And deleting the resource block deletes the real monitor, silently. Treat a removed check with the same suspicion as a dropped table, because you will not notice until the thing you stopped watching breaks.
Treat the state file as a secret
If a check needs basic auth, that password reaches the provider through your config, and Terraform state has a long memory: anything persisted there can be read by anyone who can read the backend. The provider marks the password sensitive, which keeps it out of plan output but not out of the state file itself, so the real protection is an encrypted state backend with narrow access. Terraform 1.11 added write-only arguments, values that are never persisted at all, and they are the right long-term answer for check credentials.
Tokens that do one job
A Terraform run should not carry a credential that can do everything. Tokens are scoped to a resource and an action, bound to one organization and given an enforced expiry, so the token in your pipeline can create monitors without also being able to delete your org.
Declare a monitor in Terraform
terraform {
required_providers {
uptimepage = {
source = "uptimepage/uptimepage"
}
}
}
resource "uptimepage_target" "api" {
name = "api prod"
interval = 60
check = {
type = "http"
http = {
url = "https://example.com/healthz"
expected_status = {
kind = "exact"
exact = 200
}
}
}
}FAQ
Which provider do I use?
What can I declare in Terraform?
Do I need the hosted service?
How does the provider authenticate?
At a glance
- Terraform provider uptimepage/uptimepage
- Resources monitors, pages, channels
- Check types HTTP, TCP, DNS, TLS, domain, ping, heartbeat, flow
- Check interval every 60s
- Auth scoped, expiring API tokens
- Price to start free, no card