Advanced Options

This page covers the type-specific options that go beyond a basic up/down check: HTTP request shaping and response validation, SSL expiry alerts, and DNS record checks. For the common fields and per-type targets, see Monitor Types.

HTTP / HTTPS Options

HTTP and HTTPS monitors let you shape the request and validate the response so the check reflects real application health, not just "the server answered."

Request Method

The method field controls the HTTP verb. Allowed values:

GET (default), POST, PUT, DELETE, HEAD, OPTIONS

• GET — the default; fetches the page or endpoint.
• HEAD — checks availability without downloading the body (lighter weight).
• POST / PUT — exercise an endpoint that expects a request body (see Request Body).

Expected Status Code

By default a monitor treats 200 as success. Set expected_status to any code from 100 to 599 when your endpoint returns something else:

A response whose status code differs from expected_status is recorded as a failure.

Expected String

Set expected_string to a substring that must appear in the response body for the check to pass. This catches the case where the server returns 200 but the page is broken, blank, or showing an error.

expected_string: "Welcome to Example"
expected_string: "\"status\":\"ok\""

If the response status matches but the expected string is missing, the check fails.

Custom Headers

Add request headers one per line in Key: Value format. Useful for authentication, content negotiation, or hitting a specific virtual host.

Authorization: Bearer abc123
Accept: application/json
X-Api-Key: my-key
Host: app.internal.example.com

Headers are parsed into key/value pairs and sent with every check.

Request Body

For POST/PUT monitors, the optional body field is sent as the request payload — for example a JSON document a health endpoint expects. Pair it with an Accept/Content-Type header for correct content negotiation.

Follow Redirects

follow_redirects is off by default. When off, a 3xx response is evaluated as-is — handy for confirming a redirect returns exactly 301/302. When on, the probe follows redirects and evaluates the final destination's status and body. Turn it on when your canonical URL redirects (for example HTTP→HTTPS or apex→www) and you care about the final page.

SSL Expiry Alerts

SSL monitors track a TLS certificate's expiry and warn you before it lapses, so a forgotten renewal never becomes an outage.

The monitor reads the certificate's validity dates on each check and enters an alerting state once the certificate is within alert_days_before_expiry days of expiring. Set a longer window (for example 30 days) to give yourself plenty of lead time to renew.

A common pattern is to run two monitors on the same host:

• An HTTPS monitor to confirm the site is up and serving correctly.
• An SSL monitor with a 30-day expiry window to catch renewal problems early.

DNS Record Checks

DNS monitors confirm that a domain resolves and, optionally, that it resolves to the value you expect — catching misconfigured records, failed propagation, or hijacked DNS.

Record types

Choose the dns_record_type that matches what you want to verify:

Matching behavior

• dns_expected empty — the check passes as long as the record resolves at all. Use this to detect a record that disappears or fails to resolve.
• dns_expected set — the resolved record must match the expected value. Use this to catch a record that changes to the wrong target.

dns_record_type: A      dns_expected: 203.0.113.10
dns_record_type: MX     dns_expected: mail.example.com
dns_record_type: TXT    dns_expected: v=spf1 include:_spf.example.com ~all

Failure and Recovery Behavior

Across all types, two thresholds control when status changes and alerts fire:

• Failure threshold — consecutive failed checks required to mark the monitor down and (if enabled) open an incident.
• Recovery threshold — consecutive successful checks required to mark it up again and resolve the incident.

These work together with retries to suppress false alarms. Notifications are gated by notify_on_failure and notify_on_recovery. For response-time anomaly alerting on HTTP/HTTPS monitors, see Anomaly Detection.

Next Steps

• Monitor Types - Per-type targets and options
• Intervals & Probes - Check frequency, timeout, retries, probes
• Alerts: Thresholds - Tune failure and recovery triggers
• Anomaly Detection - ML response-time alerting
• Monitors Overview - Lifecycle and common fields