One Signal, Many Audiences

Uptime Kuma does not send every piece of monitoring evidence to every reader. It turns classified heartbeats into different projections: a detailed private dashboard, a selective notification, a public status page, a badge, or a Prometheus gauge. Understanding those output boundaries helps the reader choose the right channel for diagnosis, immediate attention, public communication, or automation without treating any one projection as a substitute for the underlying history.

The difference is not merely presentation. Each audience needs a different balance of detail, freshness, privacy, and attention. An operator investigating an outage wants messages and retry context. A customer needs a clear current status and an explanation of planned work, not a response body containing internal details. An automation system needs stable numerical signals and labels. Uptime Kuma's output layer adapts the same heartbeat to these needs, and every adaptation creates both value and loss.

Alerts are policy, not raw telemetry

A notification begins with a state decision already made. The monitor has performed its configured check, applied its retry and maintenance rules, and marked the heartbeat according to whether it represents a meaningful transition. Uptime Kuma then applies a narrower notification policy. A first observed failure can be sent, as can an outage or recovery transition; a routine first-up result does not pass the same notification condition. Repeated successful checks and repeated failures remain part of history without producing an alert each time. A continuing outage can generate a resend after a configured number of down checks.

This is attention management layered over evidence. If a service is checked every few seconds, forwarding every successful result would drown the recipient in routine messages. Forwarding every failed attempt would make a transient network error look like a confirmed incident. By notifying on selected transitions, Uptime Kuma keeps the event stream available for inspection while reserving attention for changes in operational state.

The policy still has consequences. A retry budget delays the notification of a final outage. A resend interval controls whether a continuing failure remains visible to a person who may have missed the first message. A maintenance window can change which transitions are treated as ordinary incidents. These choices should be evaluated against the cost of a late alert, a noisy alert, and an alert that arrives without enough context to act on it.

Notification configuration is stored separately from monitor configuration and connected through a relation. At startup, Uptime Kuma registers provider implementations behind a common dispatch method. The monitor supplies a message and, for state changes, monitor and heartbeat information. The provider-specific adapter handles the destination's protocol. This separation means adding or selecting a destination does not require the monitor loop to understand every messaging API.

The adapter boundary is also a failure boundary. Uptime Kuma attempts delivery to each configured provider and logs an error if an individual provider fails. That prevents one broken destination from interrupting the monitor's entire cycle. It does not create a durable queue or guarantee eventual delivery.