Getting started with Standby
The two apps, the agent, and why the status page runs somewhere else.
Standby is two applications and an agent. Running them apart is deliberate and is the single most important thing to understand before installing.
The pieces
| Piece | What it does |
|---|---|
| on-call | Incidents, escalation, schedules, silences, the admin UI |
| status | The public status page — its own app, its own database, its own host |
| probe | Outside checks: HTTP, TCP, ICMP, SSL and DNS, from more than one region |
| agent | Runs on each of your machines and reports in |
Why status runs separately
The status page exists to be readable during an outage. If it shared a host or a database with on-call, the incident that took on-call down would take the page with it — exactly when people are loading it.
So on-call pushes HMAC-signed events to the status app — incident published, update posted, resolved, component status changed — and the status app applies them to its own store and regenerates a static snapshot. An audience arriving all at once reads a file, not a render.
What the agent needs
Outbound reach to your install. You do not open an inbound port to it. It runs on Debian, Ubuntu, RHEL, SUSE, Alpine and Windows, and reports metrics, logs, package inventory, backup state and security events.
The order things happen in
- Install on-call and its Postgres.
- Install status on a different host, with its own Postgres, and give it the shared HMAC secret.
- Install the agent on the machines you want covered.
- Add outside probes for anything you want checked from the internet rather than from itself.
- Set up escalation chains and an on-call schedule, so an alert reaches a person rather than a dashboard.