Skip to main content
Monitors are the core building block of DevHelm. A monitor defines what to check, how often, from where, and what counts as failure.
Define monitors in code. Manage monitors as part of your monitoring-as-code workflow: YAML format · Terraform · CI/CD patterns

​
Monitor types

DevHelm supports six monitor types:

HTTP

Web endpoints, APIs, health checks. Supports headers, auth, TLS verification, and 11 assertion types.

TCP

Port connectivity checks. Verify services accept connections with response time thresholds.

DNS

Domain resolution. Verify records resolve correctly with expected values, TTLs, and response times.

ICMP

Host reachability via ping. Measure response time and packet loss.

MCP Server

AI tool server availability. Verify MCP servers start, respond, and list expected tools.

Heartbeat

Passive monitoring. Your service pings DevHelm — an incident opens if pings stop arriving.

​
Check flow

For active monitors (HTTP, TCP, DNS, ICMP, MCP Server):
  1. DevHelm runs checks from each configured probe region at the set frequency
  2. Each check evaluates all assertions and records a result (pass/fail)
  3. Results flow into the incident policy engine
  4. If the policy’s trigger rules are met, an incident is created and alerts fire
  5. When the monitor recovers, the incident auto-resolves per the recovery policy
For heartbeat monitors, the flow is reversed — your service sends periodic pings to a DevHelm endpoint. If a ping doesn’t arrive within the expected interval plus grace period, the monitor is marked as down.

​
Frequency

Check frequency is configurable from 30 seconds to 86,400 seconds (24 hours). The default is 60 seconds. Minimum frequency depends on your plan.
PlanMinimum frequency
Free300s (5 min)
Starter60s (1 min)
Pro30s

​
Regions

Monitors run from one or more probe regions. Multi-region checks enable the incident policy to require failures from multiple locations before opening an incident, reducing false positives. 
devhelm monitors create \
  --name "API Health" \
  --type HTTP \
  --url https://api.example.com/health \
  --regions us-east,eu-west

​
Assertions

Assertions define what “healthy” means for your monitor. Each assertion has a severity (fail or warn) and type-specific configuration.
  • fail severity — contributes to incident creation when the assertion fails
  • warn severity — records a DEGRADED severity hint but doesn’t directly trigger DOWN incidents
Every monitor type has its own assertion set. HTTP monitors have the most options (11 types), while simpler protocols like TCP have 3.
Monitor typeAvailable assertions
HTTPstatus_code, response_time, body_contains, json_path, header, regex, ssl_expiry, response_size, redirect_count, redirect_target, response_time_warn
TCPtcp_connects, tcp_response_time, tcp_response_time_warn
DNSdns_resolves, dns_response_time, dns_expected_ips, dns_expected_cname, dns_record_contains, dns_record_equals, dns_txt_contains, dns_min_answers, dns_max_answers, dns_response_time_warn, dns_ttl_low, dns_ttl_high
ICMPicmp_reachable, icmp_response_time, icmp_response_time_warn, icmp_packet_loss
MCP Servermcp_connects, mcp_response_time, mcp_has_capability, mcp_tool_available, mcp_min_tools, mcp_protocol_version, mcp_response_time_warn, mcp_tool_count_changed
Heartbeatheartbeat_received, heartbeat_max_interval, heartbeat_interval_drift, heartbeat_payload_contains

​
Assertion operators

Where an assertion uses an operator field, the options are:
OperatorBehavior
equalsExact match
containsSubstring match
less_thanNumeric less-than
greater_thanNumeric greater-than
matchesRegex match
rangeNumeric range

​
Authentication

HTTP monitors support authenticated requests via vault secrets. Store credentials in the encrypted vault, then reference them by ID in your monitor configuration.
Auth typeWhat it sends
bearerAuthorization: Bearer <token>
basicAuthorization: Basic <base64>
headerCustom header with secret value
api_keyNamed header with API key value
See Secrets for vault management and HTTP configuration for auth setup.

​
Incident policy

Every monitor has an incident policy that controls when incidents open and close. The policy has three components:
  • Trigger rules — conditions that open an incident (consecutive failures, failures in window, response time)
  • Confirmation — multi-region confirmation to prevent false positives
  • Recovery — how many passing checks are required before auto-resolving
See Incident policies for full details.

​
Management modes

Monitors track who manages them via the managedBy field:
ModeSet byMeaning
DASHBOARDDashboard or APIManaged through the UI or direct API calls
CLIdevhelm deployManaged by YAML config-as-code
TERRAFORMTerraform providerManaged by Terraform state
Don’t manage the same monitor through both YAML and Terraform. Pick one source of truth per resource.

​
Next steps

HTTP monitors

The most feature-rich monitor type — endpoints, APIs, TLS, assertions.

Monitors guide

Step-by-step guide to creating and configuring monitors.

First HTTP monitor

Create your first HTTP monitor end-to-end.

Monitoring as Code

Define monitors in YAML.