Your First HTTP Monitor

By the end of this guide, you’ll have an HTTP monitor checking your endpoint every 60 seconds from multiple regions, with results visible in the Dashboard.

Prerequisites

DevHelm CLI installed (npm install -g devhelm) or an API token for REST calls
An API token set as DEVHELM_API_TOKEN — see Authentication
A publicly accessible URL to monitor

Create the monitor

Pick your surface

Choose whichever method fits your workflow:

devhelm monitors create \
  --name "My API Health" \
  --type HTTP \
  --url https://api.example.com/health \
  --frequency 60 \
  --regions us-east,eu-west

version: "1"
monitors:
  - name: My API Health
    type: HTTP
    config:
      url: https://api.example.com/health
      method: GET
    frequencySeconds: 60
    regions:
      - us-east
      - eu-west

curl -X POST https://api.devhelm.io/api/v1/monitors \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My API Health",
    "type": "HTTP",
    "config": {
      "url": "https://api.example.com/health",
      "method": "GET"
    },
    "frequencySeconds": 60,
    "regions": ["us-east", "eu-west"]
  }'

If using YAML, deploy it:

devhelm deploy -f devhelm.yml

Verify it's running

Check that the monitor was created and is collecting results:

devhelm monitors list
devhelm monitors get <monitor-id>

You should see the monitor with status ACTIVE and check results appearing within 60 seconds.

View results

Open the Dashboard to see check results, response times, and status codes plotted over time. Or fetch results via the CLI:

devhelm monitors checks <monitor-id> --limit 5

Add assertions

By default, an HTTP monitor passes if it gets any response. Add assertions to define specific pass/fail criteria:

devhelm monitors create \
  --name "My API Health" \
  --type HTTP \
  --url https://api.example.com/health \
  --frequency 60 \
  --regions us-east,eu-west \
  --assertion 'status_code=200' \
  --assertion '{"severity":"fail","config":{"type":"response_time","thresholdMs":2000}}'

curl -X POST https://api.devhelm.io/api/v1/monitors/<monitor-id>/assertions \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "severity": "fail",
    "config": {
      "type": "status_code",
      "expected": "200",
      "operator": "equals"
    }
  }'

monitors:
  - name: My API Health
    type: HTTP
    config:
      url: https://api.example.com/health
      method: GET
    frequencySeconds: 60
    regions:
      - us-east
      - eu-west
    assertions:
      - config:
          type: status_code
          expected: "200"
          operator: equals
        severity: fail
      - config:
          type: response_time
          thresholdMs: 2000
        severity: fail

In the CLI, the repeatable --assertion flag is set at create time and accepts a shorthand DSL (status_code=200, response_time<2000, ssl_expiry>=14) or a JSON object when you need full control over severity and config. To add assertions to an existing monitor, use the assertions API (POST /api/v1/monitors/{monitorId}/assertions) as in the API tab. Common assertions for HTTP monitors:

Type	What it checks
`status_code`	Response status equals or matches a pattern
`response_time`	Response completes within a threshold
`body_contains`	Response body includes a string
`json_path`	A JSON path evaluates to an expected value
`header_value`	A response header matches an expected value
`ssl_expiry`	TLS certificate is valid for at least N days

For the full list, see HTTP assertions.

What happens next

Once your monitor is running:

Passing checks appear as green dots in the Dashboard timeline
Failing checks (assertion failures, timeouts, connection errors) appear as red dots
Incidents are created automatically based on the monitor’s incident policy — by default, 2 consecutive failures trigger a DOWN incident
Alerts fire through your notification policies when an incident is confirmed

Next steps

HTTP monitor reference

All HTTP configuration options and assertion types.

First alert

Get notified when this monitor fails.

Multi-region monitoring

Reduce false positives with cross-region confirmation.

Monitoring as Code

Manage monitors in YAML and deploy from CI.

Overview

Getting Started

Monitoring Guides

Alerting Guides

Incident Guides

Status Data Guides

Monitoring as Code Guides

Your First HTTP Monitor

Create the monitor

Add assertions

What happens next

Next steps

HTTP monitor reference

First alert

Multi-region monitoring

Monitoring as Code

​Create the monitor

​Add assertions

​What happens next

​Next steps

HTTP monitor reference

First alert

Multi-region monitoring

Monitoring as Code

Create the monitor

Add assertions

What happens next

Next steps