Skip to content

Welcome

Self-hosted, developer-first observability. Uptime monitoring, live dashboards, the incident lifecycle, and customer-facing status pages — running on your hardware, owning your data.

Self-hosted, developer-first observability. Uptime monitoring, live dashboards, the incident lifecycle, and customer-facing status pages — running on your hardware, owning your data.

Pulse is one binary for the API + one binary for the worker, backed by Postgres (with TimescaleDB) and Redis. The web app is a static SPA. It runs comfortably on a single 2 vCPU / 2 GB host and scales by adding workers.

What Pulse does today

Section titled “What Pulse does today”
  • Synthetic monitoring — HTTP, TCP, and heartbeat checks, with optional SSL expiry alerts.
  • Multi-region dispatch — workers in any region you operate; aggregation rules (any / majority / all) decide when a monitor is considered down.
  • Incidents — auto-opened on threshold breach, manually declared from the dashboard, or linked to alert rules. Severity P1–P5, full status lifecycle, comments, postmortems.
  • Alerts — rule-based DSL: monitor scope (all / by tag / specific) × trigger (status, latency, SSL, heartbeat) × notification channels (Slack, Discord, Telegram, Email, Webhook).
  • Status pages — public, brandable, custom-domain-capable, with subscriber notifications and RSS.
  • SLOs — per-monitor target % and time window, achieved %, error budget, burn rate.
  • Multi-tenant ready — multiple orgs per install, gated behind a feature flag for the common single-org case.

What Pulse is not

Section titled “What Pulse is not”
  • Not an APM. There are no traces, profiles, or in-process instrumentation.
  • Not a log platform. Use Loki / ELK / Vector for log aggregation.
  • Not a SaaS. You run it on your own hardware. (You can host it for others, but Pulse itself doesn’t ship a multi-tenant SaaS control plane.)

Who this docs site is for

Section titled “Who this docs site is for”

The product source-of-truth for product behaviour is the running code in your install. If a doc here disagrees with the app, file an issue.

Next steps

Section titled “Next steps”
  • Quickstart — zero to working install in ten minutes.
  • Core concepts — the small set of terms the rest of the docs uses.
  • Self-hosting — for operators preparing a production deploy.