MONITORING AS CODE

Monitors are files. Review them like code.

Define checks, alerts and status pages in devhelm.yml or Terraform, deploy from CI, and let your agent work with them through MCP.

Five ways in: the CLI, a Terraform provider (beta), TypeScript and Python SDKs, an MCP server and a GitHub Action.

5 developer surfaces · all on Free · 50 uptime monitors · 4 regions · no credit card

Book a demo Read the docs

version: "1"
alertChannels:
  - name: Engineering Slack
    config:
      channelType: slack
      webhookUrl: ${SLACK_WEBHOOK_URL}
monitors:
  - name: API health
    type: HTTP
    config:
      url: https://api.acme.dev/health
      method: GET
    frequencySeconds: 300
    regions: [us-east, eu-west]
    alertChannels: [Engineering Slack]
    assertions:
      - config: { type: status_code, expected: "200", operator: equals }
        severity: fail
      - config: { type: response_time, thresholdMs: 800 }
        severity: warn

$ devhelm plan -f devhelm.yml
$ devhelm deploy -f devhelm.yml

WHY MONITORING DRIFTS

Your app is in git. Your monitors are in someone's browser tab.

The monitor nobody can diff is the one that is wrong when you need it.

A threshold changed in a form has no pull request, no author, and no way to keep staging and production on the same definition. The same monitor in the repo is a diff someone approved.

Before

In a dashboard

No review before the threshold changes
No history of who changed it
Staging and production drift apart

After

In your repo

Pull-request review
Git blame on the line that pages you
One definition per environment
Dashboard edits show up as drift in devhelm plan

Start free — no credit card

CLI AND GITHUB ACTION

From commit to monitor in three commands

Run them in your terminal, or let the GitHub Action run them on every pull request.

Validate and plan on the pull request, deploy on merge. The file covers HTTP, DNS, TCP, ICMP, heartbeat and MCP server checks, with assertions on status code, response time, body or JSON, SSL expiry and DNS records.

1
Initdevhelm init scaffolds devhelm.yml in the repo. devhelm validate devhelm.yml checks it offline against the schema.
2
Plandevhelm plan -f devhelm.yml lists what will be created, updated or deleted. Nothing changes yet.
3
Deploydevhelm deploy -f devhelm.yml applies the plan. In CI, add --yes to skip the prompt.

Read the CLI docs Monitoring-as-code guide

$ npm install -g devhelm
$ devhelm init
$ devhelm validate devhelm.yml
$ devhelm plan -f devhelm.yml
$ devhelm deploy -f devhelm.yml

name: Monitors
on:
  pull_request:
    paths: ['devhelm.yml']
  push:
    branches: [main]
    paths: ['devhelm.yml']

jobs:
  monitors:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: devhelmhq/setup-devhelm@v1
        with:
          api-token: ${{ secrets.DEVHELM_API_TOKEN }}
      - run: devhelm validate devhelm.yml
      - run: devhelm plan -f devhelm.yml
      - if: github.ref == 'refs/heads/main'
        run: devhelm deploy -f devhelm.yml --yes

Monitors · Example workspace

TERRAFORM PROVIDER · BETA

Your infrastructure is in Terraform. Put the monitors there too.

Review the plan before it pages anyone.

devhelmhq/devhelm on the Terraform Registry. Monitors, alert channels, notification policies, status pages and their components, dependencies, resource groups, environments and secrets are all resources.

terraform plan shows the change. terraform apply ships it.

Read the Terraform provider docs

terraform {
  required_providers {
    devhelm = {
      source  = "devhelmhq/devhelm"
      version = "0.2.0-beta.9"
    }
  }
}

resource "devhelm_monitor" "api" {
  name              = "API health"
  type              = "HTTP"
  frequency_seconds = 300
  regions           = ["us-east", "eu-west"]

  config = jsonencode({
    url    = "https://api.acme.dev/health"
    method = "GET"
  })

  assertions {
    type   = "status_code"
    config = jsonencode({ expected = "200", operator = "equals" })
  }

  alert_channel_ids = [devhelm_alert_channel.slack.id]
}

resource "devhelm_alert_channel" "slack" {
  name         = "Engineering Slack"
  channel_type = "slack"
  webhook_url  = var.slack_webhook_url
}

resource "devhelm_status_page" "public" {
  name        = "Acme"
  slug        = "acme"
  description = "Live status of Acme services."
}

resource "devhelm_status_page_component" "api" {
  status_page_id = devhelm_status_page.public.id
  name           = "API"
  type           = "MONITOR"
  monitor_id     = devhelm_monitor.api.id
}

MCP SERVER

Your agent reads the incident. You still merge the change.

Claude Code or Cursor can create monitors, adjust them and pull incident timelines while it writes the feature.

Connect to the hosted server at https://mcp.devhelm.io/mcp with a bearer token, or run it locally with uvx devhelm-mcp-server. For changes you want reviewed, have the agent edit devhelm.yml and merge the pull request yourself.

About 128 tools across monitors, incidents, alert channels, status pages and dependencies
create_monitor, update_monitor, list_incidents, get_incident_timeline, track_dependency, get_service_live_status
Monitoring your own MCP server is a separate check type, on every plan

Set up the MCP server

{
  "mcpServers": {
    "devhelm": {
      "command": "uvx",
      "args": ["devhelm-mcp-server"],
      "env": { "DEVHELM_API_TOKEN": "dh_live_xxxxxxxx" }
    }
  }
}

Example conversation

You: Why did API health page us last night?

Agent → list_incidents, get_incident_timeline

Agent: Three failed checks from eu-west, then recovery. Here is the timeline.

WHAT SHIPS

Five developer surfaces. All of them on Free.

Commercial use allowed, no credit card. Paid plans raise limits: more monitors, faster intervals, higher API rates. They don't unlock any developer surface.

Everything the dashboard does is a REST API call. Rate limits are per organization: 100 requests a minute on Free, 1,000 on Starter, 5,000 or more on Pro and above. Alerts go to 20 integrations on every plan, including Slack, PagerDuty, Opsgenie, Microsoft Teams and webhooks.

CLI	`npm install -g devhelm`
Terraform provider (beta)	`devhelmhq/devhelm`
SDKs	TypeScript `@devhelm/sdk` on npm, Python `devhelm` on PyPI
MCP server	`https://mcp.devhelm.io/mcp` or `uvx devhelm-mcp-server`
GitHub Action	`devhelmhq/setup-devhelm@v1`

Open the API reference See pricing

FAQ

Frequently asked questions

Plan gating, drift, rollback and agent access.

Is monitoring as code available on the Free plan?

Yes. The CLI, Terraform provider (beta), SDKs, MCP server and GitHub Action are on every plan, including Free, with commercial use allowed and no credit card.

CLI or Terraform, which should I use?

Use the CLI when the monitor file should travel with the app repo. Use the Terraform provider when the environment is already a Terraform plan. Both are on every plan.

Can the dashboard and my repo both edit a monitor?

Yes, but the file wins. devhelm plan shows dashboard edits as drift, and the next devhelm deploy overwrites them with the YAML definition.

How do I roll back?

Revert the commit that changed devhelm.yml and deploy again. Run devhelm plan -f devhelm.yml first to see exactly what the revert changes.

Which SDK languages are there?

TypeScript (@devhelm/sdk) and Python (devhelm). Anything else can call the REST API.

Does it work with Pulumi?

Not today. Use the Terraform provider or the REST API.

Can an agent change my monitors safely?

It can change them directly, within the token you give it: the MCP server acts on your workspace through the API, and changes apply at once. If you want a review step, keep monitors in devhelm.yml and have the agent open a pull request instead.

Book a demo

Ship the monitor in the same PR as the feature

Start free, commit one file with your monitors and an alert channel, get your first alert. No credit card.

npm install -g devhelm

Book a demo