Home / Docs / Reliability & Alerting

Start

Reliability & Alerting

How PulseBeacon confirms failures before alerting — and why you will not get false alarms.

PulseBeacon is built so that a single network blip never becomes a false alarm. Failures are confirmed with follow-up probes before any status change, alert, or public status page update happens. This page explains exactly how that works.

Monitor Statuses

Badge Meaning
OperationalLatest confirmed result is healthy.
Confirming…A probe just failed and PulseBeacon is re-checking. This is not an outage — no alert has been sent, and status pages still show the last confirmed state.
WarningDegraded but reachable — for example an SSL certificate expiring soon, or a heartbeat that is late but not yet missing.
DownThe failure was confirmed by consecutive probes (or is definitive, such as an expired certificate). This is the only state that produces DOWN alerts and public outage display.
PausedMonitoring and alerting are turned off for this monitor.

How Failure Confirmation Works

  1. A probe fails (timeout, DNS problem, connection error, unexpected HTTP status, keyword mismatch, closed port…).
  2. The monitor enters Confirming… — its public status does not change and nothing is alerted yet.
  3. PulseBeacon re-probes with short spacing. By default a failure must repeat on 3 consecutive probes before the monitor is marked Down.
  4. If any confirmation probe succeeds, the incident is cancelled: the monitor stays up and the blip is logged in the activity feed as a transient failure — with no notification.
  5. Only when the failure is confirmed does the status flip to Down, exactly one DOWN alert go out per channel, and status pages show the outage.

Definitive failures skip confirmation

Some verdicts cannot change on retry — an invalid monitor configuration, or an SSL certificate that was actually retrieved and is expired, self-signed, or issued for the wrong hostname. These are marked Down immediately, because re-checking cannot produce a different answer.

Inconclusive is never Down

If a probe cannot produce a trustworthy result (an internal error, for example), PulseBeacon records it as inconclusive and leaves the monitor status untouched. Unknown never counts as an outage.

Alert Behavior

  • Alerts fire on confirmed state transitions only — never on individual failed probes.
  • One DOWN alert per channel when an outage is confirmed; one recovery alert when the monitor is confirmed healthy again.
  • Identical repeated transitions are deduplicated with a cooldown window across every channel (email, webhook, Slack, Telegram, Discord); suppressed sends are recorded with a reason.
  • Unconfirmed flapping (fail–recover–fail–recover) produces zero notifications.
  • Sensitive values (authorization headers, tokens, URL credentials) are redacted from alert payloads and logs.

Uptime Calculation

  • Uptime percentages and daily history bars count confirmed downtime only.
  • Transient blips that never got confirmed do not reduce uptime.
  • Warning states (for example an expiring SSL certificate) do not count as downtime.

Per-Type Notes

Monitor type Reliability behavior
HTTP / Keyword / PortFull confirmation flow as described above.
SSLHealthy certificates are checked about once a day (no minute-level probing needed); unhealthy or expiring certificates re-check roughly hourly so fixes recover quickly. Network problems are confirmed before any Down; a certificate that is genuinely expired or invalid is definitive.
HeartbeatEscalation is staged: after the expected ping window plus your grace period the monitor becomes Late (warning), and only after a further full schedule window does it become Down. The grace period absorbs normal cron jitter and queue delays.
Server (agent)Marked offline when no metrics arrive within the offline window; resource alerts (CPU/memory/disk) fire once per threshold crossing and once on recovery.

What Status Page Visitors See

  • Public status pages always display the confirmed state of each component.
  • A monitor that is Confirming… still shows its last confirmed state publicly — visitors never see raw unconfirmed probe failures.
  • Warning states (such as an expiring certificate) appear as Degraded, not as an outage.