Skip to main content
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.
  • 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

1

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
2

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.
3

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:
TypeWhat it checks
status_codeResponse status equals or matches a pattern
response_timeResponse completes within a threshold
body_containsResponse body includes a string
json_pathA JSON path evaluates to an expected value
header_valueA response header matches an expected value
ssl_expiryTLS 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.