ProductFeaturesPricingDownloadChangelogDocs
Sign inStart free
monitors
Monitors

Endpoint Monitors

Endpoint monitors perform periodic HTTP checks against any URL. DataRunner records status and response time on every probe, opens an incident when consecutive checks fail past your threshold, and resolves it automatically when the endpoint recovers.

Read
7 min
Sections
6
Min interval
30 s

How monitors work

Each monitor runs a probe cycle:

  1. DataRunner sends an HTTP request to your URL at the configured interval
  2. The response status code is compared to your expected code (default 200)
  3. A match records the check as up; any mismatch or timeout records it as down
  4. When consecutive down checks reach the failure threshold, an incident opens and alerts fire
  5. 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

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.

PreviousWatchesNext Hosts