Skip to content
9n9s Docs

Guide: Configuration as Code

Configuration as Code (CaC) allows you to manage your 9n9s monitors, projects, and alert rules using declarative definition files, which can be version-controlled in Git and applied automatically. This is ideal for teams managing large or complex monitoring setups.

Start with the Dashboard: Before implementing Configuration as Code, create your first monitors through the web interface to understand 9n9s concepts and workflows. Then export your configuration as a starting point for your code-based setup. See our Getting Started guide first.

9n9s will support several CaC methods:

  • Terraform Provider
  • Pulumi Provider
  • YAML/JSON Definitions applied via the CLI

This guide provides an overview of the YAML definition method.

Defining Monitors in YAML

Section titled “Defining Monitors in YAML”

You can define your monitors in a 9n9s.yml file. Here is an example that defines both a Heartbeat and an Uptime monitor.

9n9s.yml
# You can define monitors for multiple projects.
# The project slug is the key.
projects:
    my-web-app:
        # List of heartbeat monitors for this project
        heartbeats:
            - slug: "daily-backup" # A unique identifier for this monitor
              name: "Daily Backup Script"
              schedule: "0 4 * * *" # Every day at 4 AM
              grace: "1h"
              timezone: "UTC"
              tags: ["backups", "production"]


            - slug: "user-sync-job"
              name: "User Sync Worker"
              schedule: "every 15 minutes"
              grace: "5m"
              tags: ["users", "production"]
              # Define min/max expected runtimes
              expected_runtime:
                  min: "1m"
                  max: "10m"


        # List of uptime monitors for this project
        uptime:
            - slug: "landing-page"
              name: "Main Website"
              target: "https://9n9s.com"
              protocol: "HTTPS"
              frequency: "1m"
              tags: ["website", "production"]
              assertions:
                  - type: "STATUS_CODE"
                    operator: "EQUALS"
                    value: "200"
                  - type: "RESPONSE_TIME"
                    operator: "LESS_THAN"
                    value: "750ms" # Milliseconds
                  - type: "TLS_CERT_EXPIRY"
                    operator: "MORE_THAN_DAYS"
                    value: "14" # Days

The slug field is a unique identifier that you define. It allows 9n9s to track the monitor across definition changes, so you can rename a monitor without it being deleted and recreated.

Applying Definitions

Section titled “Applying Definitions”

Once you have your 9n9s.yml file, you can apply it using the CLI. This will create, update, or delete monitors to match the state defined in your file.

Terminal window
# Preview the changes that will be made
9n9s-cli cac diff --file /path/to/9n9s.yml


# Apply the changes
9n9s-cli cac apply --file /path/to/9n9s.yml

Running apply in a CI/CD pipeline after a Git commit is a great way to automate your monitoring setup. For example, when a new service is added to your codebase, you can add its corresponding monitor to the YAML file in the same pull request. Once merged, the pipeline will automatically create the monitor in 9n9s.