Uptime Monitoring as Code

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?

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

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

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.