Skip to content

Core concepts

The small set of terms Pulse uses. Read this once before clicking around.

The model is small and worth understanding before you click around.

A thing you check periodically. Has a kind (http, tcp, heartbeat), a target, an interval, and a derived status (operational, degraded, down, paused).

A single attempt by a worker to evaluate a monitor. Stored in the monitor_results hypertable (TimescaleDB) so 90-day uptime queries stay fast. Carries ok / status_code / response_time_ms / region / error.

The process that runs checks. Runs anywhere with outbound HTTPS to the API. Enrolls with a one-shot token, then talks long-lived agent creds. Each worker reports a region (iad, fra, sin, etc.).

How multi-region results aggregate per monitor:

  • all — every region must fail for status to flip to down.
  • majority — strictly more than half the regions failing.
  • any — one failing region is enough.

Default is majority when ≥3 regions check the monitor, else all.

An open episode. Auto-opened by the alert engine when a rule’s condition stays matched across the configured threshold, or declared manually from the dashboard. Severity P1–P5, status investigating | identified | monitoring | resolved. Has comments, optional postmortem.

(monitor_selector, conditions, channel_ids). Eval’d on every state change. Fires once per match; auto-resolves after N consecutive ok checks.

Notification destination. Per-channel config carries the destination (Slack webhook URL, Telegram bot token + chat id, email recipient, custom webhook URL).

Public-facing view: components grouped, current overall status, active incidents with update timelines, 90-day uptime strip, optional maintenance windows. Servable from a custom domain.

Tenant boundary. Monitors, incidents, status pages, channels, members all scope to one org. Most installs have exactly one. Multi-org switching is gated behind ENABLE_MULTI_ORG.