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
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 assertions create <monitor-id> \
  --type status_code \
  --expected 200 \
  --operator equals

devhelm assertions create <monitor-id> \
  --type response_time \
  --threshold-ms 2000
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.