resource "devhelm_monitor" "api_health" { name = "API Health" type = "HTTP" frequency_seconds = 60 regions = ["us-east", "eu-west"] config = jsonencode({ url = "https://api.example.com/health" method = "GET" verifyTls = true }) assertions { type = "status_code" # `expected` is a STRING — quote it, even for plain numeric codes config = jsonencode({ expected = "200", operator = "equals" }) }}
JSON value types inside config and assertions[].config must match the API
contract exactly — status_code.expected is a string
(expected = "200", not expected = 200), while response_time.thresholdMs
is a number. Type-mismatched values plan cleanly but fail apply with
“Provider produced inconsistent result” because the API normalizes them on
the round-trip.
HTTP authentication. Pick exactly one of bearer, basic, header, or api_key; each variant takes a vault_secret_id (UUID of a devhelm_secret). header and api_key also require header_name.
Repeatable block for pass/fail criteria. The block name is assertions (plural); repeat it once per assertion:
Attribute
Type
Required
Description
type
string
Yes
Assertion type discriminator in snake_case wire format. 42 types are supported, validated at plan time against the API spec. Common ones: status_code, response_time, body_contains, header_value, regex_body, json_path, ssl_expiry, redirect_count, redirect_target, response_size; plus per-type families dns_* (e.g. dns_resolves, dns_record_equals, dns_ttl_low), tcp_* (tcp_connects, tcp_response_time), icmp_* (icmp_reachable, icmp_packet_loss), heartbeat_* (heartbeat_received, heartbeat_max_interval), mcp_* (mcp_connects, mcp_tool_available), and *_warn variants
config
string (JSON)
Yes
Assertion configuration as JSON; the inner type field is omitted (set via the sibling type attribute). Field names inside config are camelCase and value types must match the API contract exactly, e.g. { expected = "200", operator = "equals" } for status_code (expected is a string) or { thresholdMs = 500 } for response_time (thresholdMs is a number)
Single nested attribute (use = assignment, not a block) controlling confirmation and recovery behavior. Omit it entirely to adopt server defaults; supplying any field overrides the policy in full.
Attribute
Type
Required
Description
confirmation_type
string
—
Confirmation strategy (e.g., multi_region)
min_regions_failing
number
—
Minimum failing regions to confirm
max_wait_seconds
number
—
Maximum confirmation wait time
consecutive_successes
number
—
Consecutive passes required for recovery
min_regions_passing
number
—
Minimum passing regions for recovery
cooldown_minutes
number
—
Minutes before auto-resolving
trigger_rules
list of objects
—
Rules that determine when failures escalate to incidents
trigger_rules[*] object:
Attribute
Type
Required
Description
type
string
Yes
consecutive_failures, failures_in_window, or response_time
severity
string
Yes
down or degraded
scope
string
—
per_region or any_region
count
number
Yes
Failure count threshold (1–10); required for all rule types
window_minutes
number
Conditional
Time window in minutes; required when type = "failures_in_window"
threshold_ms
number
Conditional
Response time threshold in ms; required when type = "response_time"
aggregation_type
string
—
all_exceed, average, p95, max
The provider enforces these conditional requirements at plan time.
Import accepts the monitor name or its UUID. If multiple monitors share the same name, the import fails with an ambiguity error listing the candidate UUIDs — import by UUID in that case.