monitors

A monitor is a URL pngr checks on a schedule. Each check runs a set of conditions against the response and produces an outcome. The monitor's state is the worst outcome across its conditions. When a monitor leaves up, an incident opens; when it recovers, the incident closes.

anatomy

creating a monitor

From the dashboard click + new monitor, or press n on the /monitors page. The form is split into sections — basics (name, url, transport, method), request (headers, body), and conditions.

New monitors seed two conditions for you: status_code: 200-299 and a generous latency fail threshold of 2000ms. Keep them, tune them, or remove them. There's a send test check action on the form that runs the conditions against the live URL before you save, so you can confirm the check passes (or see exactly why it doesn't) without waiting for the scheduler.

$ pngr monitor create \
    --name "api · staging" \
    --url https://api.staging.example.com/health \
    --interval 60s \
    --status 200-299 \
    --latency-max 800ms

actions

From a monitor's detail page (/monitors/[id]) you can:

• run check now — fire an immediate check and see the result synchronously, instead of waiting for the next scheduler tick.
• pause / resume — see pausing vs deleting below.
• edit — change any field. Editing conditions takes effect on the next check.
• delete — soft-delete (see below).

The detail page also carries the status timeline chart (below), per-window uptime and latency percentiles, and the monitor's incident history.

lifecycle

1. Create — the monitor enters pending. The scheduler picks it up within ~10s.
2. First check — outcome decides the state. All conditions pass → up. A warn → degraded. A fail → down. A monitor that fails its very first check opens an incident straight out of pending.
3. Steady state — last_checked_at updates every check. Any check where all conditions pass returns the monitor to up, regardless of the previous state. There is no separate state machine — see monitor states.
4. Recover — the first passing check after degraded/down closes the open incident automatically and returns the monitor to up.

status timeline

The headline visual on the detail page is a single bar chart that answers both is this OK? and how fast is it? at a glance:

• bar color = the worst outcome in that time bucket — green (all pass), yellow (a warn), red (a fail), or muted gray (no data).
• bar height = latency. Per-check latency on the 1h view; bucket p95 on the 24h and 7d views.

Three range tabs — 1h (one bar per check), 24h (15-minute buckets), 7d (hourly). The 24h view uses 15-minute buckets on purpose: a 30-minute outage would otherwise hide inside a single hourly bar. Hovering a bar shows the bucket's timestamps, the pass/degraded/down breakdown, p95/p99 latency, and the most recent failure reason when the bar is red or yellow.

pausing vs deleting

Pause stops checks but keeps the monitor and its full history. Use it during planned outages, deploy windows, or while you debug a flaky endpoint — no incidents open while paused, and the timeline is intact when you resume.

Delete is a soft-delete with a 30-day recovery window before the record is purged.