Glossary

The words used in alerting, on-call and incident response, defined in a sentence or two. Where a guide covers a term in depth, the definition links to it.

Acknowledge (ack): The on-call person telling the system "this is mine". Acknowledging stops the escalation timer, so nobody further down the policy is notified. It does not mean the problem is fixed. Read the guide.
Actionable alert: An alert that needs a human to do something now. The usual test: if the person paged could reasonably do nothing, it should not have paged them. Read the guide.
Alert: A notification from a monitoring system that a condition was met: a check failed, a metric crossed a threshold, a ping was missed. Several alerts can belong to one incident.
Alert fatigue: What happens when people get more alerts than they can act on: they start to ignore, mute or snooze them, and real problems get missed. Read the guide.
Alert grouping (deduplication, correlation): Combining alerts that share a cause or a label into one notification or incident, so one outage does not produce fifty pages. Read the guide.
Blameless postmortem: A review after an incident that looks for the conditions that made the failure possible, not a person to blame. The aim is that people describe what happened honestly. Read the guide.
Burn rate: How fast a service is spending its error budget. A burn rate of 1 uses the whole budget exactly over the SLO window; alerting on a high burn rate catches fast failures without paging on every blip. Read the guide.
Dead man's switch (heartbeat check, cron monitoring): A check that alerts when an expected signal stops arriving. A job pings a URL each time it runs; if the ping does not arrive on time, the check fails. Read the guide.
Error budget: The amount of unreliability an SLO allows. A 99.9% monthly availability target leaves about 43 minutes of downtime a month to spend. Read the guide.
Escalation: Moving an unacknowledged alert to the next person or group after a set wait. Also used for a responder deliberately pulling in more help. Read the guide.
Escalation policy (escalation chain): The ordered rules for who is notified about an alert and when: level 1 first, then level 2 after a wait if nobody acknowledged, and so on, sometimes repeating. Read the guide.
Flapping: A check that keeps switching between failing and passing, sending a stream of open and resolve notifications. Usually fixed with a longer evaluation window or hysteresis. Read the guide.
Follow the sun: An on-call model where responsibility passes between teams in different time zones, so whoever is on call is working in daylight hours. Read the guide.
Four golden signals: Latency, traffic, errors and saturation. Proposed in the Google SRE book as the minimum to monitor for a user-facing system. Read the guide.
Handover (handoff): The change from one on-call person to the next at the end of a shift, ideally with a short note on anything still open. Read the guide.
Incident: An unplanned problem that affects, or may affect, a service and needs a response. One incident can have many alerts, or none if a person reported it. Read the guide.
Incident commander (incident lead): The person who coordinates an incident: decides who does what and when to escalate, and keeps communication going. They usually do not fix things themselves. Read the guide.
Maintenance window: A planned period in which alerts for certain services are suppressed, so expected downtime does not page anyone.
MTBF (mean time between failures): The average time a system runs between one failure and the next. Read the guide.
MTTA (mean time to acknowledge): The average time from an alert firing to someone acknowledging it. It measures how well paging and escalation work. Read the guide.
MTTD (mean time to detect): The average time from a problem starting to monitoring noticing it. It measures the quality of your checks. Read the guide.
MTTR (mean time to resolve, repair, recover or respond): The average time to fix an incident. The R has at least four meanings in use, so state which one you measure and when the clock starts. Read the guide.
On-call: Being the person responsible for responding to alerts for a service during a set period, including outside working hours. Read the guide.
Override (substitution, swap): A temporary change to a schedule where one person covers part of another person's shift, without editing the rotation itself. Read the guide.
Page: An urgent notification that expects a response now, whatever the hour. From the pagers once carried by on-call staff.
Primary and secondary: Two on-call roles for the same period. The primary gets the page first; the secondary is the next escalation level if the primary does not acknowledge. Read the guide.
RED method: Rate, errors and duration: three metrics to watch for every request-driven service. Described by Tom Wilkie. Read the guide.
Rotation (rota, roster, schedule): The order in which people take turns on call, and how long each turn lasts. A schedule can combine several rotations as layers. Read the guide.
Runbook (playbook): Written steps for handling a specific alert or task. A good alert links to its runbook so the person paged knows where to start. Read the guide.
Severity (SEV, priority): A label for how bad an incident is, such as SEV1 to SEV4 or P1 to P5. It decides who is paged, how fast, and who has to be told. Read the guide.
Silence (mute, snooze): Stopping notifications for matching alerts for a while, without turning the check off. Alertmanager uses the word for label-matched suppression.
SLA (service level agreement): A promise to customers about a service level, usually with a penalty such as credits if it is missed. Read the guide.
SLI (service level indicator): A measurement of service quality, such as the share of requests served in under 300 ms. Read the guide.
SLO (service level objective): A target for an SLI over a window, such as 99.9% of requests succeeding over 30 days. SLO-based alerts page when the target is at risk. Read the guide.
Status page: A page that tells users whether a service is working, and posts updates during incidents and maintenance. Read the guide.
Synthetic monitoring: Running scripted requests or browser journeys against a service on a schedule, so failures are found before users report them.
Toil: Manual, repetitive operational work that grows with the service and could be automated. The Google SRE book uses the term.
USE method: Utilisation, saturation and errors for every resource, such as CPU, disk and network. Described by Brendan Gregg for finding performance bottlenecks. Read the guide.