monitors

Monitors

Endpoint Monitors

Monitors run periodic checks against the things your product depends on — an HTTP endpoint, a TCP port, a DNS name, a TLS certificate, a domain registration, one of your database connections, or a heartbeat from a job that has nothing to probe. DataRunner records status and response time on every probe, opens an incident when consecutive checks fail past your threshold, and resolves it automatically on recovery.

Read: 7 min
Sections: 7
Min interval: 30 s

How monitors work

Each monitor runs a probe cycle:

DataRunner sends an HTTP request to your URL at the configured interval
The response status code is compared to your expected code (default 200)
A match records the check as up; any mismatch or timeout records it as down
When consecutive down checks reach the failure threshold, an incident opens and alerts fire
When the next check comes back up, the incident closes automatically and an recovery alert fires

Creating a monitor

Go to Monitors → New monitor. Configure:

Name — descriptive label for this monitor
URL — the full HTTP or HTTPS URL to probe
Method — GET, HEAD, or POST (default: GET)
Expected status code — the HTTP status that counts as “up” (default: 200)
Timeout — request timeout in milliseconds, 1 000—30 000 (default: 10 000)
Check interval — seconds between probes, minimum 30 (default: 60)
Failure threshold — consecutive failing checks before an incident opens (default: 3)
Alert recipients — email addresses or a broadcast list to notify on status change

API health endpoint

Example

URL:      https://api.example.com/health
Method:   GET
Interval: 60s
Expect:   HTTP 200
Timeout:  10 000 ms

Webhook receiver

Example

URL:      https://hooks.example.com/ingest
Method:   POST
Interval: 120s
Expect:   HTTP 200
Timeout:  10 000 ms

Public dashboard (HEAD check)

Example

URL:      https://dashboard.example.com
Method:   HEAD
Interval: 300s
Expect:   HTTP 200
Timeout:  5 000 ms

Monitor kinds

A monitor is not only an HTTP check. The kind decides what is probed and which fields the editor asks you for.

http

Requests a URL and checks the status code, plus optional body assertions and a latency budget.

tcp

Opens a TCP connection to a host and port. Use it for databases, brokers, and anything without an HTTP surface.

dns

Resolves a name and checks that it answers. Catches the failure mode where the service is fine but nobody can find it.

ssl_cert

Watches certificate expiry on a host and raises the alarm before the browser does.

domain_expiry

Tracks domain registration expiry via RDAP. The outage nobody monitors until it happens once.

database

Tracks the health of one of your configured connections, so a database outage shows up next to the endpoints that depend on it.

heartbeat

A dead-man switch, inverted from the others: instead of DataRunner calling you, your job calls a secret ping URL. Miss the expected interval plus a grace period and the monitor goes down. This is how you monitor a cron job or an ETL that has no endpoint to probe.

HTTP body assertions

An HTTP monitor can look past the status code. A 200 that returns an error page is still an outage:

contains — the response body must contain a substring
not_contains — the response body must not contain a substring — good for catching a stack trace or a maintenance banner
jsonpath_eq — a dotted path into the JSON body must equal an expected value, e.g. data.status equals ok

Two extras worth knowing: a latency SLO fails the check when a response is slower than the budget you set, even if it succeeded; and latency anomaly detection can flag a response-time z-score against the recent baseline as an informational alert, without failing the check.

HTTP probes

DataRunner supports three HTTP methods for probes:

GET — standard request; fetches the full response body. Use for most endpoints.
HEAD — fetches headers only; no response body transferred. Faster and lighter for large pages or files.
POST — sends an empty POST body. Use for endpoints that reject GET requests.

The expected status codeis the exact HTTP status that counts as “up”. Any other status — including 3xx redirects — counts as a failure. Set the expected code to match exactly what a healthy response returns from your endpoint.

The timeout is clamped between 1 000 ms and 30 000 ms. If the endpoint does not respond within the timeout, the probe records a failed check with a timeout error.

HEAD for lightweight checks: If you are monitoring a page or file that returns a large response body, use HEAD to check availability without downloading the payload on every probe.

Incidents & alerts

An incident opens when the number of consecutive failing checks reaches the failure threshold (default: 3). Each incident records:

Started at — timestamp of the first failing check in the sequence
Resolved at — timestamp of the first passing check after the incident
Duration — total downtime in seconds

Alerts fire in two moments: when an incident opens (status changes up → down) and again when it resolves (down → up). Configure alert recipients on the monitor's settings using email addresses or a broadcast list.

Tuning the failure threshold: With the default threshold of 3, a single transient timeout will not open an incident. Lower it to 1 for stricter alerting, or raise it to reduce noise from endpoints with occasional slow responses.

Pause and resume

Pause a monitor to stop probing without deleting it — useful during planned maintenance windows. Open the monitor and click Pause. A paused monitor shows status inactive and will not run checks, open incidents, or send alerts.

Click Resume to restart probing. DataRunner begins a fresh probe cycle immediately on resume.

Check history

The Checks tab on each monitor shows a paginated log of every probe result: timestamp, HTTP status code, response time in milliseconds, and error message (if any). Use this to diagnose intermittent failures or review response time trends over time.

The Incidents tab lists all recorded downtime events with start time, resolution time, and total duration in seconds.