● Alwaysbeat

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).