Overview
This series explains how Uptime Kuma turns service-specific observations into heartbeats, state transitions, historical summaries, and audience-specific outputs. It shows how monitor choice, retries, maintenance, freshness, retention, exposure, and deployment dependencies shape what a result can support—and where a signal stops short of proving universal service health.
Learning outcomes
- A green result means only that a configured assertion passed from a particular vantage point.
- Retries, maintenance, groups, and push timing change how observations become actionable states.
- Uptime percentages summarize counted observations, not continuous availability for every user or moment.
- Public pages, alerts, badges, and metrics are useful projections with different freshness, privacy, and evidence limits.
- Self-hosting gives control over data and execution, but makes dependencies, credentials, and exposure the operator's responsibility.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What does Uptime Kuma actually prove when a monitor is up?
It proves that the configured assertion passed from the selected vantage point; it does not prove every dependency, user path, or region is healthy.
How should you choose an Uptime Kuma monitor?
Choose the monitor by the failure you need to expose, such as reachability, content, structured readiness, DNS, browser navigation, container state, or job reporting.
What does Uptime Kuma's uptime percentage measure?
It is the fraction of counted UP observations among UP and DOWN observations, not continuous availability for every user or millisecond.
How do you know whether a self-hosted Uptime Kuma signal is trustworthy?
Check the assertion and vantage point, state policy, heartbeat freshness, audience exposure, and dependencies before making a broader reliability claim.