The Uptime Monitoring Glossary: Terms Every Small Team Should Know
Plain definitions of the words that show up in monitoring dashboards, alert messages, status pages, and service agreements, followed by answers to the questions we hear most often.
- Alert fatigue
- The state a team reaches when alerts fire so often, or so pointlessly, that people stop reading them. It is the most common way a monitoring setup fails, and it is prevented by confirmation thresholds, careful routing, and deleting alerts that are never acted on.
- Availability
- The share of time, or the share of checks, during which a service was working over a given period, usually expressed as a percentage. Availability depends entirely on how a failed check is defined, so two monitors can report different numbers for the same service.
- Check interval
- How often a monitor sends a probe to an endpoint. Shorter intervals detect outages faster and catch brief ones, at the cost of more requests to your servers and more sensitivity to transient network problems.
- Confirmation threshold
- The number of consecutive failed checks, or the number of locations that must agree, before a monitor declares an incident and alerts. It trades a small detection delay for far fewer false alarms.
- Degraded performance
- A status page state meaning the service is responding but slower than normal or with partial functionality. It signals to customers that you are aware of a problem that falls short of a full outage.
- DNS monitoring
- Checks that verify a domain resolves to the expected records from outside your network. Catches expired registrations, propagation problems, and accidental record edits that make a healthy server unreachable.
- Downtime
- Time during which a service fails its monitoring checks. Whether a slow or partially working service counts as downtime depends on the thresholds you set, which is why the definition should be written down and kept stable.
- Error budget
- The amount of downtime permitted by a service level objective over a period. If the objective is 99.9% over 30 days, the budget is roughly 43 minutes, and spending it quickly is a signal to slow down risky changes.
- Escalation policy
- The ordered list of who is notified, through which channel, and after how long, when an incident is not acknowledged. A typical policy moves from a chat channel to a phone call to a second responder.
- False positive
- An alert for a failure that did not actually affect users, such as a single checker losing its own network connection. Multi-location checks and confirmation thresholds are the primary defenses.
- Health endpoint
- A dedicated URL in an application that performs lightweight checks on its critical dependencies, such as the database and cache, and returns a clear pass or fail. Monitoring a health endpoint catches problems a static homepage would hide.
- Heartbeat check
- A monitor that expects a periodic ping from a scheduled job or background worker and alerts when the ping stops arriving. Sometimes called a dead man's switch, it makes invisible failures in cron jobs and queues visible.
- HTTP status code
- The three-digit code a web server returns with each response. Codes in the 200 range indicate success, 300 range redirects, 400 range client errors, and 500 range server errors. Monitors usually treat 5xx responses and timeouts as failures, but a 200 does not guarantee the page is correct.
- Incident
- A period during which a service is failing or degraded, from detection to resolution. On a status page, an incident is the unit that groups updates, affected components, and the eventual postmortem.
- Keyword check
- A check that passes only if the response body contains, or does not contain, a specific string. It catches maintenance pages, error templates, and empty responses that still return a successful status code.
- Latency
- The time between sending a request and receiving a response. Rising latency often precedes an outage, so monitoring it separately from availability gives early warning.
- Maintenance window
- A scheduled period during which monitoring alerts are suppressed and the status page shows planned work. It prevents expected downtime from paging the team or counting against availability targets.
- Mean time to detect (MTTD)
- The average time between the start of an outage and the moment the team becomes aware of it. Check interval and confirmation threshold are the two settings that most directly control it.
- Mean time to resolve (MTTR)
- The average time between the start of an outage and full recovery. Runbooks, clear alert messages, and practiced escalation reduce it; detection delays lengthen it.
- Monitoring location
- The geographic point from which a checker sends probes. Using several locations reveals regional problems and prevents a single checker's own network issues from being reported as your outage.
- Nines
- Shorthand for availability percentages: two nines is 99%, three nines is 99.9%, four nines is 99.99%, and five nines is 99.999%. Each additional nine cuts the permitted annual downtime by a factor of ten and typically raises the engineering cost sharply.
- Postmortem
- A written review of an incident covering what happened, why, how it was detected and resolved, and what will change. Blameless postmortems focus on systems and process rather than individuals and are the main source of monitoring improvements.
- Real user monitoring (RUM)
- Collecting performance and error data from actual visitors' browsers or devices. It shows what real people experienced across networks and devices you did not script, and complements synthetic checks rather than replacing them.
- Runbook
- A short, step-by-step document describing how to respond to a specific alert. Linking a runbook from the alert message lets someone who did not build the system handle the first response.
- Service level agreement (SLA)
- A contractual commitment to customers about availability or performance, usually with credits or other remedies if it is missed. It should be set looser than your internal objective so a normal bad month does not trigger penalties.
- Service level indicator (SLI)
- The specific measurement used to judge service quality, such as the share of checks that succeed or the share of requests answered within a latency threshold. Uptime monitoring is usually the source of availability SLIs.
- Service level objective (SLO)
- The internal target for an SLI over a period, such as 99.9% successful checks over a rolling 30 days. It is the number the team manages to, and it defines the error budget.
- SSL certificate expiry
- The date after which a site's TLS certificate is no longer valid, causing browsers to show security warnings and most clients to refuse the connection. Certificate monitoring warns days or weeks ahead so renewal never becomes an outage.
- Status page
- A public web page, hosted independently of your main infrastructure, showing the current state of each customer-facing component along with active and past incidents. Its purpose is to tell customers whether a problem is on their side or yours.
- Synthetic monitoring
- Scripted checks that run on a schedule from outside your network, from a single HTTP request to a multi-step browser transaction that logs in and completes a purchase. It detects outages before customers report them and provides consistent, comparable measurements.
Questions people ask
What is the difference between uptime monitoring and application performance monitoring?
Uptime monitoring checks from the outside whether a service is reachable and responding correctly, at a fixed interval, and alerts when it is not. Application performance monitoring instruments the code from the inside to explain why it is slow or failing, using metrics, traces, and logs. Small teams usually start with uptime monitoring because it is cheap and answers the most urgent question, then add deeper tooling when diagnosis becomes the bottleneck.
How many monitoring locations do I actually need?
Enough to form a majority when one of them has a problem, which in practice means at least three. Spread them across regions that matter to your customers. More locations improve confidence and reveal regional issues, but beyond a handful the marginal value drops for a small product.
Why does my site show as down when I can load it fine?
The most common causes are a single checker location with its own network trouble, a firewall or rate limiter blocking the monitor's requests, a keyword check that no longer matches because the page changed, or a timeout threshold set too aggressively. Check the failure details from each location before assuming the monitor is wrong; sometimes a regional outage is real even though it does not affect you.
Should uptime checks hit the homepage or a health endpoint?
Both, for different reasons. The homepage check confirms that the public face of the product loads, including the CDN and certificate. A health endpoint check confirms that the application and its dependencies, such as the database, are actually working. Monitoring only the homepage is the classic way to be green during a real outage.
How quickly should I be alerted after an outage starts?
For customer-facing services, most small teams aim to know within a few minutes. That comes from a 1 to 3 minute check interval combined with a confirmation threshold of two or three consecutive failures. Faster is possible but usually adds false alarms without changing the outcome, since a human still needs time to respond.
What should be on a status page for a small SaaS?
A short list of customer-facing components such as the web app, the API, and background processing, each with a clear state; any active incident with timestamped updates; a history of past incidents; and a way to subscribe to updates. Host it on a separate domain and infrastructure so it stays reachable during your outages.
How do I monitor a cron job or background worker?
Use a heartbeat check. The job sends a request to a unique URL each time it completes successfully, and the monitor alerts if the expected ping does not arrive within a grace period. This converts a silent failure into an alert without exposing the job over HTTP.
Does 99.9% uptime mean my site was down for a full 0.1% of every day?
No. Availability is measured over a period, usually a month or a year, and downtime can be concentrated in one incident. Over a 30 day month, 99.9% permits roughly 43 minutes of downtime in total, whether that is one 43 minute outage or many short blips. The reporting period and the definition of a failure both matter when comparing numbers.
What is the right way to handle planned maintenance in monitoring?
Schedule a maintenance window in your monitoring tool so alerts are suppressed and the downtime is excluded from availability figures, and post the window on your status page in advance. Announce it to subscribers, keep it as short as possible, and confirm on the status page when it is finished.
Can uptime monitoring detect a hacked or defaced website?
Partially. A keyword check that looks for content only present on the legitimate page will fail if that content is replaced, and a certificate check will catch some tampering with TLS. Uptime monitoring is not a security tool, though, and it should not be relied on as one; it is a useful early signal rather than a defense.
How do I stop false alarms without missing real outages?
Check from multiple locations and require a majority to agree, require two or three consecutive failures before alerting, set timeouts that reflect real response times rather than ideal ones, and use maintenance windows for planned work. Then review every alert after the fact and adjust one rule at a time.
What should the first incident update on a status page say?
That you are aware of a problem, which components are affected, and when the next update will come. It does not need a cause or a fix. Posting within minutes of confirming the incident matters more than posting something complete, and committing to an update cadence keeps customers from assuming you have gone quiet.
Is response time monitoring necessary if availability is already tracked?
Yes. A service can pass every availability check while being slow enough that customers give up. Rising response times also tend to precede outright failures, which makes latency a useful early warning. Track both, with separate thresholds, and report response time percentiles alongside availability.