Working with Uptime Kuma — or any monitoring tool — means wading into a swamp of acronyms. SLA, SLO, SLI, MTTR, MTTD, MTBF, uptime, availability, heartbeat, push monitor, pull monitor, tag, group, incident, maintenance window, status page. Some of these terms are interchangeable, some are subtly different, and some are used loosely in marketing copy in ways that are actively confusing. This glossary is the plain-English reference — every term a UK sysadmin, developer or business owner will realistically encounter when working with Uptime Kuma, defined without jargon and with a note on how it maps to the actual Uptime Kuma UI. If you are new to the product, our introduction to Uptime Kuma is the better starting point, and this page is the reference you come back to.
How to use this glossary
Read the sections that interest you, or use Ctrl+F on the page to jump to the term you care about. Definitions lead with a one-sentence plain-English summary, then add context on how the term is used in Uptime Kuma specifically. Terms with particularly common misunderstandings also have a short "watch out" note.
A - D
Alert. A notification generated when a monitor changes state from up to down (or, in some configurations, the reverse). In Uptime Kuma alerts are routed to one or more notification channels configured per monitor. Contrast with an incident, which is the human-written record of what happened; the alert is the automated signal that starts the incident.
API (Application Programming Interface). A way for programs to talk to other programs. In Uptime Kuma there is a built-in API for querying monitor status and pushing heartbeats; it is particularly useful for wiring monitoring into automated deployments. Not to be confused with the public-facing API of services you monitor — those are the endpoints your monitors hit.
Apprise. A third-party notification library that Uptime Kuma ships as a first-class channel. Apprise itself speaks to roughly 100 downstream targets, so the Apprise integration effectively multiplies the notification options available — particularly useful for obscure destinations the built-in channels do not cover directly.
Availability. The percentage of time a service is reachable and behaving as expected. Usually expressed as a percentage over a window — "99.9% availability over the last 30 days". Subtly different from uptime, which strictly counts the percentage the service is running; availability adds the requirement that the service is also responding usefully.
Backup. A point-in-time copy of your Uptime Kuma database. In self-hosted deployments, backups are your responsibility; in a managed deployment on smartxhosting.uk, they run daily on the provider side.
Badge. A small image that shows the current status of a monitor or status page, suitable for embedding in GitHub README files or external documentation. Uptime Kuma generates badge URLs automatically for any monitor or status page.
Baseline. The expected normal behaviour of a service. A monitor that compares real-time behaviour against a baseline can detect performance drift, not just hard outages. Uptime Kuma does not do statistical baselining natively — it flags against fixed thresholds — but the concept is worth knowing when comparing with Datadog, New Relic and friends.
Certificate (SSL/TLS). The cryptographic document that proves a site is who it says it is and encrypts traffic to and from it. Uptime Kuma's HTTP(s) monitor can be configured to fail not only on connection errors but also on certificate expiry or chain issues, which is one of the most underused features in the product.
Check. A single attempt by a monitor to verify that a service is up. Not to be confused with monitor (the configured entity) or heartbeat (the signal a push monitor waits for). Each monitor runs a check at its configured interval.
CNAME. A type of DNS record that aliases one name to another. Uptime Kuma's DNS monitor can watch CNAME records for unexpected changes — useful for catching accidental or malicious redirections of traffic.
Dashboard. The main internal Uptime Kuma view where all your monitors are visible at a glance. Distinct from a status page, which is the external-facing version shared with customers. Only logged-in users see the dashboard; anyone with the URL can see the status page (unless it is password-protected).
DNS. The Domain Name System — the mechanism that translates names like example.com into IP addresses. Uptime Kuma has a dedicated DNS monitor type; our HTTP(s) monitoring guide covers the adjacent HTTP checks that most teams set up first.
Docker. The container runtime most commonly used to install Uptime Kuma. From v2 onwards, the official image runs rootless by default for security reasons.
Downtime. The period during which a service is not available. The inverse of uptime; more useful in incident reviews and SLA calculations than in day-to-day monitoring. Note that "downtime" usually excludes scheduled maintenance windows — see below.
E - H
Endpoint. A specific URL or network address that a monitor checks. Distinct from the full service — a service typically has multiple endpoints (login page, API health, checkout, admin). Monitoring each independently is the standard pattern; monitoring only the homepage is the beginner mistake.
Failure threshold. The number of consecutive failed checks before Uptime Kuma declares the monitor down and fires an alert. The default is two, which is a sensible balance between sensitivity and false alarms. Setting it to one produces noisier monitoring; setting it to five hides genuine short outages.
False positive. An alert fired for an outage that did not happen (usually a transient blip that Uptime Kuma was sensitive enough to detect but not to dismiss). The opposite of a false negative, where a real outage goes undetected. Both erode trust in the monitoring system; false positives more so, because they train the team to ignore alerts.
Group. An Uptime Kuma construct that lets you bundle related monitors under a single parent. Status pages can surface groups rather than individual monitors, showing customers "Payments: OK" instead of five underlying component monitors.
Grafana. A popular visualisation platform. Uptime Kuma can push monitor data to Grafana for teams that want richer dashboards than the built-in Uptime Kuma UI provides.
Heartbeat. A small signal sent from a monitored service to Uptime Kuma at regular intervals. The term is used both for the internal check a pull monitor performs and — more specifically — for the messages that a push monitor waits to receive. A missed heartbeat means something went wrong upstream.
HTTP(s). The Hypertext Transfer Protocol, the foundation of web traffic. HTTPS is the encrypted version. Uptime Kuma's HTTP(s) monitor is the workhorse of the product — most deployments use it for the majority of their checks.
Hook (Webhook). A URL that Uptime Kuma posts to when a monitor changes state. Webhooks are the universal escape hatch for integrating Uptime Kuma with systems that lack a built-in notification channel.
I - M
Incident. The human-written record of what happened during an outage, typically published on a status page. Distinct from an alert — the alert is the automated signal, the incident is the annotated narrative your users read.
Interval. How often a monitor runs its check. In Uptime Kuma, intervals are configured per monitor. The default is 60 seconds; the practical lower bound is about 20 seconds.
JSON Query. A monitor type that hits a JSON endpoint and evaluates a JSONPath expression against the response. Useful for API health-checks that return structured data rather than a simple 200 OK.
JSONPath. The query language used by the JSON Query monitor to navigate JSON documents. Similar to XPath for XML. If you are unfamiliar, the Uptime Kuma documentation includes a short primer.
Keyword monitor. A monitor type that fetches a page and searches the response body for (or without) a specified keyword. Particularly useful for catching "maintenance mode" pages that return HTTP 200 but are not actually serving the site.
Latency. The time between sending a request and receiving the first byte of the response. Uptime Kuma measures and records latency on every HTTP(s) check; latency trends are often a leading indicator of an outage.
Maintenance window. A pre-declared period of planned downtime. Monitors configured against a maintenance window do not count the resulting failures against uptime figures and do not fire alerts. Essential for avoiding noise during scheduled deploys.
Monitor. The core Uptime Kuma concept — a configured check against a specific target. Each monitor has a type (HTTP, DNS, Ping, Keyword, etc), an interval, retries, notification channels and a history.
MTBF (Mean Time Between Failures). The average time between outages. A measure of how often things go wrong. Useful in reliability engineering; less useful as a day-to-day monitoring metric because outages are not evenly distributed.
MTTD (Mean Time To Detect). The average time between an outage starting and it being detected. This is the number monitoring compresses directly — good monitoring makes MTTD approximately equal to the monitor interval.
MTTR (Mean Time To Recover). The average time between an outage being detected and the service being restored. Monitoring does not reduce MTTR directly; engineering does. But shorter MTTD helps indirectly by starting the recovery clock earlier.
N - R
Notification channel. A destination to which Uptime Kuma sends alerts — an email address, a Slack webhook, a Telegram bot, a PagerDuty service. Uptime Kuma 2.x ships 91 notification channel types. See our SMTP notifications guide for the most common setup.
Observability. The broader discipline Uptime Kuma sits at the edge of. Observability typically refers to traces, metrics and logs — much deeper than simple up/down monitoring. Uptime Kuma is good at monitoring, not at observability; if you need the latter, you complement it with Prometheus, Grafana, Loki or similar.
Outage. A period during which a service is not working as intended. Usually the customer-facing word for what your monitoring might call "monitor down".
Ping (ICMP). The low-level network check that has been around since the dawn of IP. Ping checks that a host responds to network-level probes, without attempting any application-layer interaction. Uptime Kuma's Ping monitor is useful for gateway and router checks but tells you nothing about whether the web app running on that host is actually working.
Port (TCP). A monitor type that simply attempts a TCP connection on a given port. A successful connection confirms something is listening; it does not confirm that the service behind the port is healthy.
Push monitor. A monitor type that waits for the monitored service to check in, rather than reaching out to check it. Used for scheduled jobs, batch processes and other scenarios where the monitored thing is not always reachable on demand.
Pull monitor. The more common pattern — Uptime Kuma reaches out at intervals to check the monitored service. All of HTTP(s), Port, Ping, DNS and friends are pull monitors. If a term is used without qualification, it usually means a pull monitor.
Reachability. Whether a network host is accessible over the network at all. A host can be reachable (responds to ping) without the service on it being healthy (the web app returns 500s). Monitor reachability separately from application health to diagnose which layer is failing.
Response time. The elapsed time between sending a request and receiving the complete response. Uptime Kuma records response time on every HTTP(s) check and shows trends in the dashboard.
Retry. The practice of re-running a failed check before declaring a monitor down. In Uptime Kuma, retries are configured per monitor; a common setting is two retries with a short interval between them, which filters out transient network blips.
S - Z
SLA (Service Level Agreement). A contractual commitment from a service provider to a customer about availability, response time, incident response or other measurable dimensions. SLAs usually include penalties for breach.
SLI (Service Level Indicator). A measurable metric that tells you whether you are meeting a service level — for example "percentage of HTTP requests returning 200 OK". The raw number.
SLO (Service Level Objective). A target value for an SLI that the team commits to internally. SLOs are tighter than SLAs — the objective is usually "99.9%" so the agreement can safely say "99.5%" with a margin of error.
SMTP. The Simple Mail Transfer Protocol. The channel Uptime Kuma uses to send email alerts. SMTP is reliable but deliverability is fiddly — the right SPF, DKIM and DMARC records are what separates an alert that arrives in seconds from one that lands in spam.
SSL certificate. See Certificate above. The term "SSL" is technically outdated — modern certificates use TLS — but the label SSL has stuck.
Status code. The three-digit HTTP response code. 200 means OK, 301 means moved permanently, 404 means not found, 500 means internal server error. Uptime Kuma's HTTP(s) monitor defaults to treating any 2xx code as success; you can narrow or widen the accepted range.
Status page. A public or private URL that shows the current and historical state of the services you are monitoring. Uptime Kuma ships with a built-in status page feature that many teams use instead of paying for a dedicated status page product.
Tag. A metadata label attached to a monitor. Tags do not affect behaviour but they are useful for filtering the dashboard and for grouping monitors on a status page by owner, environment or criticality.
Timeout. The maximum time a check is allowed to wait for a response before declaring failure. Too short, and slow-but-working services flap; too long, and genuine outages take noticeably longer to detect.
TLS. The modern name for SSL. Transport Layer Security. The current standard is TLS 1.3.
Uptime. The percentage of time a service is running, usually expressed as a number with many nines — 99.9%, 99.99%, 99.999%. See also availability.
Uptime Kuma. The monitoring tool this glossary is about. Open-source, MIT-licensed, 84K+ GitHub stars. Started by Louis Lam in 2021. Current stable release is 2.x.
URL. The specific web address that an HTTP(s) monitor checks. Not to be confused with the domain; a single domain can have many monitored URLs.
Version. In Uptime Kuma, v1 is the legacy line (Vue 2) and v2 is the current stable (Vue 3 + MariaDB support). Staying on v1 is discouraged; Vue 2 reached end-of-life in December 2023.
Webhook. See Hook above.
Zero-downtime deployment. A deployment pattern where new versions replace old ones without the service becoming unreachable. Monitoring with a one-minute interval usually cannot distinguish a genuine zero-downtime deploy from a genuine outage — one reason maintenance windows are worth configuring around planned releases.
Common confusions worth untangling
Uptime vs Availability. Uptime measures whether the service is running. Availability measures whether it is running and responding usefully. A server that is up but returning HTTP 500 to every request has 100% uptime and poor availability. Most business conversations really mean availability.
SLA vs SLO vs SLI. SLI is the number you measure. SLO is the internal target for that number. SLA is the external commitment with financial penalties. You pick your SLO inside the SLA with margin to spare.
MTTR vs MTTD. MTTD is detect time — how long until you notice the outage. MTTR is recover time — how long from noticing to fixing. Monitoring reduces MTTD directly; it reduces MTTR only indirectly by starting the clock earlier.
Monitor vs Check vs Heartbeat. A monitor is the configured entity. A check is one run of that monitor. A heartbeat is the signal a push monitor waits for. People use all three interchangeably in conversation; be more precise in documentation.
Alert vs Notification vs Incident. An alert is the automated signal a monitor generates when it changes state. A notification is the message that delivers the alert to a human destination. An incident is the human-curated record of what happened, usually published on a status page.
The managed Uptime Kuma offer on smartxhosting.uk uses exactly the vocabulary in this glossary. You log in, create the admin account, and configure monitors, notification channels and status pages using the terms defined above. The provider handles the platform (server, reverse proxy, SSL, backups, updates); you handle the application.
Summary and where to go next
Monitoring has its own dialect, and like any technical dialect it rewards careful use. Once you can tell an SLI from an SLO, a push monitor from a pull monitor, a keyword check from a status-code check, you will find the rest of the Uptime Kuma documentation — and this blog — noticeably easier to read. If you want to put the terms into practice, the natural follow-on guides are our HTTP(s) monitoring guide for the most common monitor type, and the SMTP notifications guide for getting alerts into an inbox you check. If you are comparing Uptime Kuma against commercial alternatives, Uptime Kuma vs Uptime Robot is the most common head-to-head for UK buyers.