comparing monitoring as code
UptimeRobot in Terraform: what the provider covers
UptimeRobot is one of the few monitoring vendors that maintains its own Terraform provider instead of leaving it to a fork. It covers more than most of the incumbents do. The gap is narrow and worth naming exactly.
The table below is the whole comparison, unedited. Read it first if you like, it is the same one we would send you.
AGPL-3.0 · one binary · free tier · no card required
Where the vendor provider stops
| UptimeRobot | Uptimepage | |
|---|---|---|
| provider from the vendor | yes | yes |
| latest release | v1.10.0, 22 Jul 2026 | shipping |
| monitors as code | yes | yes |
| alerting as code | alert contacts | channels |
| status page as code | page and announcements | yes |
| components as code | no resource | yes |
| incidents as code | no resource | open from checks |
| self-host it | no | yes, AGPL |
The provider lives at uptimerobot/terraform-provider-uptimerobot in UptimeRobot's own GitHub organization and publishes as uptimerobot/uptimerobot. Latest release v1.10.0 on 22 July 2026, commits this month.
Its resources are monitor, monitor_group, alert_contact, integration, maintenance_window, psp and psp_announcement. There is no component, incident or subscriber resource.
The registry badge reads community, which means the publisher is unverified rather than third-party. Uptimepage carries the same badge.
Verified 11 August 2026 against the provider's repository. Providers ship often, so check before you decide.
It is genuinely the vendor's
The repository is uptimerobot/terraform-provider-uptimerobot, in UptimeRobot's own GitHub organization, published to the registry as uptimerobot/uptimerobot. Latest release v1.10.0 on 22 July 2026, with commits this month. The registry badge reads community, which here means HashiCorp has not verified the publisher, not that a stranger wrote it. Read the owning organization and the last release date; the badge alone will mislead you.
What it manages
Seven resources as of August 2026: monitor, monitor_group, alert_contact, integration, maintenance_window, psp and psp_announcement. So the checks, how they are grouped, who gets paged, planned maintenance, and a public status page with announcements posted to it. That is a real monitoring-as-code story, and more than Pingdom or Statuspage can offer from any namespace they own.
The gap is incidents and components
There is no incident resource, no component resource and no subscriber resource. Announcements are the only way the page speaks, and someone writes them by hand rather than a failing check opening them. If your reason for putting this in code was an audited trail of what broke and who was told, that part stays in the dashboard.
The component that ties the page to a real check
resource "uptimepage_target" "api" {
name = "api"
interval = 60
check = {
type = "http"
http = {
url = "https://example.com/healthz"
expected_status = { kind = "exact", exact = 200 }
}
}
}
resource "uptimepage_status_page" "public" {
slug = "acme"
name = "Acme Status"
}
resource "uptimepage_status_page_component" "api" {
status_page_id = uptimepage_status_page.public.id
target_id = uptimepage_target.api.id
}Where Uptimepage fits
The Uptimepage provider covers the parts that stop at the page boundary elsewhere: the status page, the components that bind it to real monitors, and the notification channels, alongside the checks. Incidents open automatically from failing checks rather than being typed, and confirmed email and webhook subscribers hear about them. Scoped, expiring tokens for the Terraform run. Hosted free with no card, or self-hosted under AGPL.
- 01Sign in with GitHub or Google. No card, no sales call.
- 02Paste a URL. The first check runs before you have finished reading this.
- 03Publish the status page, or export it to Terraform and keep it in Git.
api99.98%
p95 142ms · one incident in 45 days
dashboard99.91%
p95 318ms · two degraded days
webhooks99.99%
p95 88ms · no incidents
RESOLVED14 min
Elevated latency on the dashboard API
14:22 resolved, latency back under 300ms
14:08 opened automatically by the dashboard check
up degraded down 45 days · email & webhook subscribers