> Markdown version of https://getuptimely.com/glossary — the page itself is the canonical copy. Glossary # The uptime monitoring glossary Every term below is one people actually search for while deciding something — what an error budget is, what MTTR measures, whether 99.9% is good. The definitions are written to be read on their own, in plain language, and where a term describes something Uptimely does not do, the entry says so. The most common starting point is [uptime meaning](https://getuptimely.com/glossary/uptime): what the percentage measures, the formula, and why the window matters. Looking for a specific HTTP or network error instead? [The error guides](https://getuptimely.com/errors) cover the codes an operator meets — 502, 504, 429, NXDOMAIN, expired certificates — from the server side rather than the browser’s. For the expired-certificate case in particular, [SSL certificate monitoring](https://getuptimely.com/features/ssl-certificate-monitoring) shows what Uptimely reads from a certificate and which rules alert on it. ## Measuring availability The numbers in the contract and the arithmetic behind them — what uptime actually counts, and what each nine costs. ### [Uptime](https://getuptimely.com/glossary/uptime) Uptime is the share of time a service was available and doing its job, expressed as a percentage of a measured window. ### [Downtime](https://getuptimely.com/glossary/downtime) Downtime is the time a service was unavailable to its users, the complement of uptime and the number that actually costs something. ### [Availability (the nines)](https://getuptimely.com/glossary/availability) Availability is the share of time a service is usable, usually stated as a target in nines, where each extra nine cuts the allowed downtime tenfold. ### [Response time](https://getuptimely.com/glossary/response-time) Response time is how long a request took to answer, measured end to end by the thing doing the asking. ### [Time to first byte (TTFB)](https://getuptimely.com/glossary/ttfb) Time to first byte is the wait from the start of a request until the first byte of the response arrives back at the browser. ### [Service level agreement (SLA)](https://getuptimely.com/glossary/sla) An SLA is a contractual promise about service quality, such as 99.9% monthly uptime, with a stated consequence when it is missed. ### [Service level objective (SLO)](https://getuptimely.com/glossary/slo) An SLO is a service level objective: the reliability target a team sets for its own service, such as 99.9% of checks passing over 28 days. ### [Service level indicator (SLI)](https://getuptimely.com/glossary/sli) An SLI (service level indicator) is the measurement a reliability target is expressed in, usually the ratio of good events to valid events. ### [Error budget](https://getuptimely.com/glossary/error-budget) An error budget is the amount of unreliability an SLO permits, treated as a resource that the team can spend. ## How checks work What a monitoring system actually does on a schedule, what each kind of check proves, and what it cannot see. ### [Probe](https://getuptimely.com/glossary/probe) A monitoring probe is one scheduled attempt to use a service from outside it, ending in a single pass or fail verdict. ### [Check interval](https://getuptimely.com/glossary/check-interval) A check interval is how often a monitor checks your service, such as every minute or every five minutes. It caps how fast an outage can be noticed. ### [Ping (ICMP)](https://getuptimely.com/glossary/ping-icmp) An ICMP ping is a network-level check that asks a host whether it is reachable, without touching any application on it. ### [HTTP status codes](https://getuptimely.com/glossary/http-status-codes) HTTP status codes are the three-digit response codes a server sends with every response: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. ### [Synthetic monitoring](https://getuptimely.com/glossary/synthetic-monitoring) Synthetic monitoring is running scripted transactions against a service on a schedule, so a broken journey is found before a real user meets it. ### [Real user monitoring (RUM)](https://getuptimely.com/glossary/real-user-monitoring) Measuring performance and errors from inside real users' browsers, using their actual sessions as the sample. ### [Heartbeat monitoring](https://getuptimely.com/glossary/heartbeat-monitoring) Monitoring that inverts the direction: your job checks in on a schedule, and silence is the alert. ### [Cron monitoring](https://getuptimely.com/glossary/cron-monitoring) Cron monitoring is checking that scheduled jobs actually ran, finished, and finished on time, usually by having each job ping a heartbeat URL. ### [DNS monitoring](https://getuptimely.com/glossary/dns-monitoring) DNS monitoring is checking that a domain's DNS records still resolve, and still resolve to what you expect. ### [SSL certificate expiry](https://getuptimely.com/glossary/ssl-certificate-expiry) The date a TLS certificate stops being valid — after which every browser refuses the connection outright. ### [Multi-location monitoring](https://getuptimely.com/glossary/multi-location-monitoring) Multi-location monitoring is running the same check from several independent networks and declaring an outage only when enough of them agree. ## Alert quality Why monitoring gets ignored, and the controls that decide whether an alert is worth waking someone for. ### [False positive](https://getuptimely.com/glossary/false-positive) A false positive is an alert for a problem that was not there, such as an uptime monitor reporting a site down while it is up. ### [Flapping](https://getuptimely.com/glossary/flapping) Flapping is when a monitor switches between up and down again and again, so every flip can send its own alert. ### [Failure threshold](https://getuptimely.com/glossary/failure-threshold) A failure threshold is the number of consecutive failed checks a monitor needs before it alerts, so one brief blip does not page anyone. ### [Alert fatigue](https://getuptimely.com/glossary/alert-fatigue) Alert fatigue is the desensitisation that follows too many alerts, after which real ones stop being acted on. ### [Degraded performance](https://getuptimely.com/glossary/degraded-performance) Degraded performance means a service is still up but not working properly: responses are slow, some requests fail, or a feature is unavailable. ## Incident response The vocabulary of a bad hour: what gets declared, who gets called, and which clocks are running. ### [Incident](https://getuptimely.com/glossary/incident) An incident is an unplanned disruption to a service, tracked as a single record from detection through to resolution. ### [Alert](https://getuptimely.com/glossary/alert) A signal that a condition was met and someone should look — the input to incident response, not the response itself. ### [Incident severity](https://getuptimely.com/glossary/incident-severity) Incident severity is a ranking of how bad an incident is, such as SEV1 to SEV3, used to decide who is woken and how fast. ### [Acknowledgement](https://getuptimely.com/glossary/acknowledgement) Acknowledgement is a responder confirming they have seen an alert and are working on it, which stops the escalation policy from paging anyone else. ### [On-call](https://getuptimely.com/glossary/on-call) On-call is the arrangement that makes one named person responsible for responding to incidents during a set period, often outside working hours. ### [Escalation policy](https://getuptimely.com/glossary/escalation-policy) An escalation policy is the set of rules that decides who is paged next, how, and after how long, when an alert is not acknowledged. ### [Mean time to detect (MTTD)](https://getuptimely.com/glossary/mttd) MTTD is the average time between a problem starting and someone knowing about it, across every incident in a period. ### [Mean time to recovery (MTTR)](https://getuptimely.com/glossary/mttr) MTTR is the average time from a problem being detected to service being restored, across every incident in a period. ### [Mean time between failures (MTBF)](https://getuptimely.com/glossary/mtbf) MTBF is mean time between failures: the average time a service runs between one failure and the next, a measure of how often it fails rather than how badly. ## After the incident Working out why it happened, writing it down, and being able to answer questions nobody thought to ask in advance. ### [Root cause analysis](https://getuptimely.com/glossary/root-cause-analysis) The investigation into why an incident happened, aimed at the conditions that allowed it rather than the trigger. ### [Postmortem](https://getuptimely.com/glossary/postmortem) A postmortem is a written account of an incident, covering what happened, why it was possible and what will change, shared once it is over. ### [Observability](https://getuptimely.com/glossary/observability) How well a system's internal state can be understood from its outputs — as opposed to monitoring, which watches known conditions. ## Telling customers The public half of an outage — the page, the subscription, the announcement, and the callback. ### [Status page](https://getuptimely.com/glossary/status-page) A status page is a public page stating whether a service is working, hosted separately so it survives the outage it reports. ### [Subscriber notifications](https://getuptimely.com/glossary/subscriber-notifications) Updates sent to customers who asked to be told when a service's status changes. ### [Maintenance window](https://getuptimely.com/glossary/maintenance-window) A maintenance window is a planned period of work on a service, announced in advance, during which disruption is expected and alerts are usually paused. ### [Webhook](https://getuptimely.com/glossary/webhook) An HTTP request one system sends to another when something happens, so the receiver does not have to poll. Missing a term you expected? Email **support@getuptimely.com** — this list grows from what people ask for. For what the product itself does, read [what’s live](https://getuptimely.com/version) or the [documentation](https://getuptimely.com/docs).