The Hund Blog

When your infrastructure grows, managing your status page monitoring through a web interface becomes a liability. Manual configuration is slow, prone to error, and easily drifts from what’s actually deployed. This creates a gap between your infrastructure and your ability to communicate its status.

The solution is to treat your status page configuration like any other part of your application: as code. By defining your components and their monitoring logic in a version-controlled repository, you gain consistency, auditability, and the ability to automate your entire incident communication stack.

This guide will walk you through how to do just that using the official Hund.io Terraform provider. This assumes you have already created your status page in the Hund.io dashboard; from there, we’ll use Terraform to manage its resources.

Why Manage Your Status Page Components as Code?

When your status page components are defined in code, you can:

• Automate Provisioning: Integrate your status page management directly into your CI/CD pipelines. When you spin up a new service, its monitoring can be provisioned automatically.
• Eliminate Drift: Ensure your status page always reflects the reality of your infrastructure.
• Maintain Consistency: Easily replicate your monitoring setup across development, staging, and production environments.
• Version and Audit: Use git history to track every change to your monitoring configuration, see who changed what, and easily roll back if needed.

Getting Started

To follow along, you’ll need two things:

1. A Hund.io account with a status page already created.
2. An API key generated from your Hund.io account dashboard.

The provider gives you access to several resources, but the two most important for building your page are hund_group and hund_component. A group is a logical collection (like "APIs" or "Databases"), and a component is a single service you want to monitor within that group. The monitoring logic itself is configured in a nested watchdog block inside each component.

A Practical Example: Building and Monitoring a Page

Let’s build out a simple status page configuration that creates a group and adds a component to monitor our main website.

First, create a file named main.tf.

# 1. Configure the Hund.io provider
# The provider will use the HUND_DOMAIN and HUND_KEY environment variables.
terraform {
  required_providers {
    hund = {
      source = "registry.terraform.io/hundio/hund"
    }
  }
}

provider "hund" {
  // Your status page domain, e.g., "status.example.com"
  domain = var.hund_domain
}

variable "hund_domain" {
  type        = string
  description = "The domain of your Hund.io status page."
}

# 2. Create a new group on your status page
resource "hund_group" "customer_services" {
  name = "Customer-Facing Services"
}

# 3. Add a component to the group and configure its monitoring
resource "hund_component" "website" {
  name        = "Main Website"
  description = "Monitors the availability of our main public website."
  group       = hund_group.customer_services.id

  watchdog = {
    service = {
      http = {
        target  = "https://example.com"
        regions = ["nj-us-1", "wa-us-1", "lon-gb-1"]

        # Mark as degraded after 2 consecutive failures
        consecutive_check_degraded_threshold = 2

        # Mark as an outage after 3 consecutive failures
        consecutive_check_outage_threshold = 3
      }
    }
  }
}

Before you run this, make sure to set your environment variables for authentication:

export TF_VAR_hund_domain="your-status-page.hund.io"
export HUND_KEY="your_api_key_goes_here"

Now, run terraform init and then terraform apply.

In under a minute, Terraform will configure your status page with a new "Customer-Facing Services" group and a "Main Website" component inside it. The watchdog block tells Hund.io to automatically perform an HTTP check against https://example.com from three different global regions every minute. Because we've set failure thresholds, the component status will automatically update to "Degraded" or "Outage" only after multiple confirmed failures, reducing false positives from temporary network blips.

Beyond the Basics

This example only scratches the surface. The real power comes when you manage your entire infrastructure this way. You can use loops to create components for dozens of microservices, use data sources to link components to existing groups, and define more complex monitoring for DNS, TCP, and other protocols.

You can also standardize your incident response by creating predefined messaging with the hund_issue_template resource for common scenarios like "API Latency Spike" or planned maintenance. From there, you can programmatically create a new incident using hund_issue and manage its entire lifecycle with hund_issue_update resources, creating a version-controlled timeline of your response. This powerful feature allows your team to manage scheduled maintenance and even active incidents as code, ensuring your communication is as robust and auditable as your infrastructure.

To explore all the available resources and options, check out the official provider documentation on the Terraform Registry.

Treating your status page as code is a fundamental shift. It moves your incident communication from a reactive, manual task to a proactive, automated part of your engineering workflow. This is essential for any team that is serious about reliability at scale.

→ Try Hund.io free for 30 days