Automation
Terraform provider
Manage your checks as code. The Alwaysbeat Terraform provider lets you declare checks alongside the infrastructure they monitor, so a new service ships with its monitoring in the same pull request.
Monitoring as code
Keeping checks in Terraform means they're reviewed, versioned, and never drift from reality —
when you delete a service, its check goes with it.
Provider configuration
The provider authenticates with an API key (create one under
Settings → API keys). Supply it via the ALWAYSBEAT_API_KEY
environment variable so it never lands in state or version control:
terraform {
required_providers {
alwaysbeat = {
source = "antonefremov/alwaysbeat"
}
}
}
provider "alwaysbeat" {
# reads the key from ALWAYSBEAT_API_KEY by default
}
A check resource
Each check is an alwaysbeat_check resource. Its attributes mirror the
HTTP API fields:
resource "alwaysbeat_check" "db_backup" {
name = "nightly-db-backup"
schedule {
kind = "cron"
cron_expr = "0 3 * * *"
tz = "Australia/Melbourne"
}
grace = "30m"
channels = ["email:ops@example.com", "webhook:https://example.com/hooks/dmf"]
max_run = "25m"
max_run_mode = "hung"
}
output "backup_ping_url" {
value = alwaysbeat_check.db_backup.ping_url
}
Reference the exported ping_url to wire the check straight into the job that
pings it — for example an EC2 user-data script, a Kubernetes CronJob manifest, or a CI step.
Availability
The provider is distributed as a separate package. For installation, the exact resource schema,
and the current version, see its page on the
Terraform Registry
and its README. The example
above shows the intended shape; the API remains the source of truth for validation (bad cron,
timezone, or duration values surface as the API's error message during
apply).