Uptime
Uptime is the share of time a service was available and doing its job, expressed as a percentage of a measured window.
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: what the percentage measures, the formula, and why the window matters.
Looking for a specific HTTP or network error instead? The error guides 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 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.
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)
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
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)
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)
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)
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)
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
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
A monitoring probe is one scheduled attempt to use a service from outside it, ending in a single pass or fail verdict.
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)
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
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
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)
Measuring performance and errors from inside real users' browsers, using their actual sessions as the sample.
Heartbeat monitoring
Monitoring that inverts the direction: your job checks in on a schedule, and silence is the alert.
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
DNS monitoring is checking that a domain's DNS records still resolve, and still resolve to what you expect.
SSL certificate expiry
The date a TLS certificate stops being valid — after which every browser refuses the connection outright.
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
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
Flapping is when a monitor switches between up and down again and again, so every flip can send its own alert.
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
Alert fatigue is the desensitisation that follows too many alerts, after which real ones stop being acted on.
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
An incident is an unplanned disruption to a service, tracked as a single record from detection through to resolution.
Alert
A signal that a condition was met and someone should look — the input to incident response, not the response itself.
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
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
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
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)
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)
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)
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
The investigation into why an incident happened, aimed at the conditions that allowed it rather than the trigger.
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
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
A status page is a public page stating whether a service is working, hosted separately so it survives the outage it reports.
Subscriber notifications
Updates sent to customers who asked to be told when a service's status changes.
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
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 or the documentation.