Uptime monitors

An uptime monitor pings a URL on a fixed interval and records the result as a heartbeat. From those heartbeats PandaStack derives a live UP/DOWN status, an uptime percentage, and — for HTTPS URLs — a TLS certificate snapshot. Monitors also drive alerts on status, latency, error rate, status codes, and certificate expiry.

What a monitor checks

Each tick, the monitor runs the configured HTTP request and evaluates the response. A probe is considered UP if and only if:

The response status is accepted (see status codes below), and
If a keyword assertion is set, the keyword appears in the response body.

Timeouts, network errors, and non-accepted statuses all produce a DOWN heartbeat with a human-readable message. The check never throws — a failure is recorded as DOWN, not as an error.

Check configuration

Field	Type	Default	Range	Notes
`name`	string	—	1–120 chars
`url`	string (URL)	—	valid URL	The endpoint to probe.
`interval`	number (s)	`60`	`30`–`86400`	Seconds between checks.
`timeout`	number (ms)	`10000`	`1000`–`60000`	Per-request timeout.
`retries`	number	`1`	`0`–`10`	Retries before marking DOWN.
`httpMethod`	enum	`GET`	`GET` \| `HEAD` \| `POST`
`statusCodes`	array	200–399	—	Accepted codes as ranges/singletons, e.g. `["200-299","401"]`. Empty ⇒ default `200-399`.
`keyword`	string	—	≤ 500 chars	Must appear in the body. Forces `GET` if `HEAD` was chosen.
`headers`	array	—	—	Custom request headers (`{ name, value }`).
`httpBody`	string	—	—	Custom request body.
`expireCertNotify`	boolean	—	—	Notify on impending TLS expiry.
`ignoreTlsError`	boolean	—	—	Ignore TLS validation errors.

Status and heartbeats

The persisted monitor status is only running (active) or pause. Live health is not stored on the monitor row — it is derived from the latest heartbeat. Heartbeat status is one of:

Heartbeat status	Meaning
`UP`	Last probe passed.
`DOWN`	Last probe failed (timeout, network error, or non-accepted status/keyword).
`PAUSE`	Monitor is paused.

Heartbeats are stored in Postgres and time-bucketed on read (no external time-series store). Old heartbeats are pruned on a retention window (default 30 days).

The check itself is run by a scheduler on every tick.

TLS certificate tracking

For https URLs, each check refreshes an SSL snapshot on the monitor: subject, issuer, validTo, and daysUntilExpiry. Combined with the ssl_expiry alert metric, this lets you catch certificates before they lapse.

Uptime percentage

Uptime is computed by time-bucketing the heartbeats table:

List and detail endpoints report a 24-hour uptime rollup. PAUSE rows are excluded from the formula.
The aggregate endpoint buckets the window to a width that yields roughly 48 buckets:

Window	Bucket width
≤ 24h	30 minutes
≤ 168h (7d)	3 hours
Larger	12 hours

Each aggregate bucket carries upCount, downCount, pausedCount, an average response time, and a per-bucket verdict. The overall verdict is down if any bucket is down, otherwise up, otherwise paused.

Alerts

Alerts fire when a condition holds over a monitor, and stamp lastTriggered when they do. Notification dispatch (email / Slack / webhook) is emitted as an effect that the API wires onto the event bus.

Alert field	Values
`metric`	`status` \| `response_time` \| `status_code` \| `error_rate` \| `ssl_expiry`
`condition`	`gt` \| `lt` \| `eq` \| `neq`
`threshold`	numeric threshold for the condition
`duration`	how long the condition must hold (1–60), default 1
`severity`	`info` \| `warning` \| `error` \| `critical` (default `warning`)
`notifications`	`{ email, slack, webhook }` — email defaults on
`state`	`active` \| `triggered` \| `inactive`

For Slack and webhook notifications, supply slackWebhook / webhookUrl on the alert.

Metrics — passive, server-side performance metrics from real traffic.
Analytics — audience insights.
Monitors API reference — every endpoint with request/response schemas.