Skip to content
OpenStatus openstatus

Understanding Monitoring as Code

The traditional approach (and its problems)

Section titled “The traditional approach (and its problems)”

Traditionally, monitoring is configured through web dashboards:

  1. Log into a web interface
  2. Click through forms to create monitors
  3. Manually replicate configuration across environments
  4. No audit trail of who changed what
  5. Difficult to review changes before they go live

This works for small teams with few monitors, but doesn’t scale.

What is monitoring as code?

Section titled “What is monitoring as code?”

Monitoring as Code treats your monitoring configuration the same way you treat your application code: as text files that can be versioned, reviewed, and deployed through automated pipelines.

Instead of clicking buttons, you define monitors in YAML:

Uptime monitoring is a vital part of any robust system, ensuring your services are online and available to users. Historically, this has involved manually configuring monitors through a web interface, which can be tedious and prone to human error. Uptime Monitoring as Code changes this by treating your monitoring configurations like any other part of your application-as code.

Why Use Uptime Monitoring as Code?

Section titled “Why Use Uptime Monitoring as Code?”

This approach offers significant advantages:

  • Version Control: By defining your monitors in a YAML file, you can track every change, rollback to previous versions, and see who made which modifications using tools like Git. This is crucial for auditing and troubleshooting.

  • Automation and Consistency: Your monitoring setup can be part of your automated deployment pipeline. When you deploy a new service, its monitors are created automatically, ensuring consistency across your entire infrastructure. This eliminates the risk of forgetting to set up monitoring for a new service.

  • Collaboration: A code-based approach simplifies collaboration among teams. A developer can create a new monitor definition in the YAML file and submit it for peer review, just as they would with any other code change. This promotes a shared understanding of your system’s health.

  • Scalability: Manually setting up hundreds of monitors is a nightmare. With a code-based approach, you can programmatically generate configurations for a large number of services, making it easy to scale your monitoring as your infrastructure grows.

  • Simplified Auditing: Since the entire configuration is in a file, it’s easy to see the current state of your monitors at a glance. You don’t have to navigate through multiple screens in a web UI.

How It Works with openstatus

Section titled “How It Works with openstatus”

We offer the use ofa simple, human-readable YAML file to define all uptime monitors. This file serves as the single source of truth for your monitoring setup. You define each monitor with its URL, expected status code, and other parameters.

Here’s an example of what your openstatus.yaml file might look like:

openstatus.yaml
# yaml-language-server: $schema=https://www.openstatus.dev/schema.json
uptime-monitor:
  name: "Uptime Monitor"
  description: "Uptime monitoring example"
  frequency: "10m"
  active: true
  regions:
    - iad
    - ams
    - syd
    - jnb
    - gru
  retry: 3
  kind: http
  request:
    url: https://openstat.us
    method: GET
    headers:
      User-Agent: openstatus
  assertions:
    - kind: statusCode
      compare: eq
      target: 200


graphql-monitor:
  name: "Graphql"
  description: "GitHub GraphQL API"
  frequency: "10m"
  active: true
  regions:
    - iad
    - ams
    - syd
    - jnb
    - gru
  retry: 3
  kind: http
  request:
    url: https://api.github.com/graphql
    method: POST
    headers:
      User-Agent: openstatus
      Authorization: Bearer YOUR_TOKEN_HERE
    body: |
      {
        "query": "query { viewer { login }}"
      }

Making Changes with the CLI

Section titled “Making Changes with the CLI”

Once your openstatus.yaml file is ready, you use our command-line interface (CLI) to apply the changes. The CLI compares your local configuration with the current state of your monitors and applies only the necessary changes creating new monitors, updating existing ones, or deleting those no longer defined.

Common CLI Commands:

  • openstatus monitors apply: Applies the changes defined in your openstatus.yaml file.
  • openstatus monitors import: Import the monitors from your dashboard to a new openstatus.yaml file.

By integrating this Uptime Monitoring as Code workflow into your development lifecycle, you can achieve a more reliable, consistent, and scalable system. It’s about moving from manual clicks to automated, version-controlled operations.

Best practices

Section titled “Best practices”
  1. Start simple: Begin with a few monitors, expand as you learn
  2. Use templates: Create reusable patterns for common monitor types
  3. Environment variables: Use secrets management for tokens and sensitive data
  4. Review changes: Always review diffs before applying
  5. Document decisions: Use commit messages to explain “why”

Next steps

Section titled “Next steps”

Ready to implement monitoring as code?