Regions and checks

HTTP, TCP, ping and DNS monitors are probed from two regions, US-East and EU-West, each running its own Blackbox Exporter. A monitor with no explicit location assignment is probed from every region; assigning it to specific locations narrows that.

The fixed 30 second scrape

Every active monitor is discovered by both regional Prometheus instances (service discovery refreshes every 30 seconds) and scraped by that region's Blackbox Exporter on a fixed 30 second interval. This is not per-monitor: a monitor's own interval_seconds gates which plan can create it (see Monitors), but it does not change how often the probe actually runs. Every monitor, on every plan, is probed on the same 30 second cadence.

A separate worker reads the latest probe result from Prometheus every 60 seconds and writes one check row per monitor per tick, using whatever the most recent scrape sample was at that moment. So in practice, a monitor's check history gets a new row roughly once a minute, drawn from a probe that itself refreshes twice as often.

What a check row contains

Check rows live in ClickHouse, not PostgreSQL, and are read back through GET /api/v1/me/monitors/{id}/checks:

{
  "checks": [
    {
      "id": "76d8caea-cbbe-48e3-bcb8-704c4e9af6eb",
      "monitor_id": "76d8caea-cbbe-48e3-bcb8-704c4e9af6eb",
      "is_successful": true,
      "response_time_ms": 261,
      "status_code": 200,
      "error_message": null,
      "created_at": "2026-09-16T13:00:10.136000Z"
    }
  ],
  "total": 1,
  "limit": 20,
  "offset": 0
}

status_code is only populated for HTTP checks. A failed check (timeout, connection refused, TLS error) carries no meaningful response_time_ms and is excluded from response-time averages for that reason.

Pending, and how long it lasts

A monitor is created in pending status and has never had a check yet. It moves to up or down on the first check row the 60-second worker writes for it, which means pending typically lasts under two minutes and, once the regional scrape has already picked the target up, often well under one. There is no separate "first check" fast path. The monitor simply waits for the same tick every other monitor waits for.

Walking this live (kind cluster): four monitors, one of each active-probe type, went from pending to up within one to two worker ticks of creation, each confirmed by polling GET /api/v1/me/monitors/{id} until status changed.

Pause, resume and status

Pausing a monitor (POST /{id}/pause) stops it from being probed and sets status to paused; it keeps its existing check history. Resuming (POST /{id}/resume) does not restore the monitor's last known status. It returns to pending and re-earns up or down from the next check, the same as a brand-new monitor.