Terraform monitoring —
manage monitoring as code

Monitoring that drifts is monitoring you can't trust

Your infrastructure lives in version control. Your monitoring usually does not. It lives in a dashboard, edited by whoever was on call, with no review, no history and no way to answer "what changed?" after an incident.

That gap is where monitoring quietly rots. An agent gets deleted to "stop the noise" and never comes back. A staging environment is torn down but its checks keep paging. Nobody can roll back a 2 a.m. edit because there is nothing to roll back to.

Declaring monitoring in Terraform closes the gap. The config sits next to the infrastructure it watches, changes go through the same pull request, and drift between the dashboard and the .tf file shows up in terraform plan like drift on anything else.

The Status Harbor Terraform provider

The statusharbor/statusharbor provider is published to the Status Harbor registry at terraform.statusharbor.io. You do not configure the hostname — terraform init resolves it from the provider namespace.

The provider is pre-1.0. Today it manages the lifecycle of Lighthouse agents — the component that probes private services from inside your network. Monitor and status-page resources are on the roadmap; this page describes what ships today, not what is planned.

Authentication is a team:admin API token, minted in the console under Settings → API Tokens and kept in a sensitive variable.

A monitoring agent in eight lines

Register a Lighthouse, mint its token and feed that token straight into the Helm deployment module — all in one terraform apply:

terraform {
  required_providers {
    statusharbor = {
      source = "statusharbor/statusharbor"
    }
  }
}

provider "statusharbor" {
  api_token = var.statusharbor_api_token
}

variable "statusharbor_api_token" {
  type      = string
  sensitive = true
}

# Register the agent and mint its token.
resource "statusharbor_lighthouse" "prod" {
  name                = "prod-vpc"
  notify_on_lifecycle = true
}

# Deploy the agent into a cluster with the minted token.
module "lighthouse_agent" {
  source = "github.com/statusharbor/terraform-lighthouse//modules/helm?ref=v0.1.0"
  token  = statusharbor_lighthouse.prod.token
}

The same module is available for Docker and cloud-init, so the agent can be deployed to a VM or a bare host with the same token output. Delete the resource and the agent is deregistered; rename it and Terraform tells you a rename is not supported rather than silently orphaning the old one.

Fits the workflow you already run

Because Lighthouse agents are ordinary Terraform resources, they go through the pipeline every other resource does. A change to monitoring is a pull request with a diff a reviewer can read. terraform plan in CI shows exactly which agents are added, changed or destroyed before anyone approves.

When you spin up a new environment, its monitoring agent is part of the same module — it comes up with the environment and is torn down with it. No separate "remember to add monitoring" step, no orphaned checks paging about a staging cluster that was deleted last week.

Frequently asked questions

Related

• Kubernetes monitoring — deploy the Lighthouse agent into a cluster with the Helm module.
• Uptime monitoring for SRE — version your alerting config so on-call changes go through review.
• SSL certificate monitoring — the silent renewal failures worth catching in code review.