# Glossary

> Every term you meet in on-call and incident response, in one or two sentences, with how Pagerless uses it.

URL: https://pagerless.dev/glossary
Updated: 2026-10-22

- [Acknowledgement](https://pagerless.dev/glossary/acknowledgement): A responder's signal that they have seen an alert and are handling it, which stops further escalation.
- [Alert fatigue](https://pagerless.dev/glossary/alert-fatigue): When responders receive so many alerts, many not actionable, that they start ignoring or muting them and miss the ones that matter.
- [Alert grouping](https://pagerless.dev/glossary/alert-grouping): Combining many related signals, such as the same error repeated, into one problem so a responder sees it once.
- [Alert noise](https://pagerless.dev/glossary/noise): Alerts that don't need anyone to act: duplicates, known background errors, bots probing dead URLs, flapping checks.
- [Blameless culture](https://pagerless.dev/glossary/blameless): Reviewing incidents by asking how the system allowed the failure rather than who caused it, so people report problems honestly.
- [Check-in (cron monitoring)](https://pagerless.dev/glossary/check-in): A ping a scheduled job sends when it runs, so a monitor can alert when a run is late, missed or failed.
- [Crash loop](https://pagerless.dev/glossary/crash-loop): A process that starts, crashes and is restarted repeatedly, usually after a bad deploy or a missing configuration value.
- [Deploy marker](https://pagerless.dev/glossary/deploy-marker): A record of when a new version went live, used to connect errors to the change that caused them.
- [Error budget](https://pagerless.dev/glossary/error-budget): The amount of unreliability an SLO allows over a period: with a 99.9% target, 0.1% of requests may fail
- [Escalation policy](https://pagerless.dev/glossary/escalation-policy): The rules for who is alerted, in what order, and how long to wait before moving to the next person when nobody acknowledges.
- [Failed deployment recovery time](https://pagerless.dev/glossary/failed-deployment-recovery-time): DORA's measure of how long it takes to recover from a deployment that fails and needs immediate intervention.
- [Fingerprint](https://pagerless.dev/glossary/fingerprint): A stable key computed from an error's type, stack and route, used to decide which events belong to the same problem.
- [Flapping](https://pagerless.dev/glossary/flapping): A check or alarm that switches between failing and healthy repeatedly in a short time, producing a stream of open and close alerts.
- [Floor signal](https://pagerless.dev/glossary/floor): A Pagerless term: a signal that always wakes someone and can never be played down by the AI
- [Heartbeat monitoring](https://pagerless.dev/glossary/heartbeat-monitoring): Detecting a dead service by expecting a regular signal from it and alerting when the signal stops.
- [Incident](https://pagerless.dev/glossary/incident): An unplanned interruption or degradation of a service that needs a response.
- [MCP (Model Context Protocol)](https://pagerless.dev/glossary/mcp): An open protocol that lets AI assistants and coding agents call tools on external services in a standard way.
- [MTTA](https://pagerless.dev/glossary/mtta): Mean time to acknowledge: the average time from an alert being sent to a responder acknowledging it.
- [MTTR](https://pagerless.dev/glossary/mttr): Mean time to recovery (or restore, or resolve): the average time from an incident starting to service being restored
- [Observability](https://pagerless.dev/glossary/observability): How well you can understand a system's internal state from what it emits: logs, metrics and traces.
- [On call](https://pagerless.dev/glossary/on-call): Being the person responsible for responding when a production system breaks during a set period, including outside working hours.
- [OpenTelemetry](https://pagerless.dev/glossary/opentelemetry): A vendor-neutral standard and set of SDKs for producing logs, metrics and traces, sent over the OTLP protocol.
- [Paging](https://pagerless.dev/glossary/paging): Interrupting a person to demand attention now, usually by push notification, phone call or SMS, named after the pagers on-call engineers once carried.
- [Postmortem](https://pagerless.dev/glossary/postmortem): A written review after an incident: what happened, the impact, the cause, and what will change so it doesn't recur
- [Rollback](https://pagerless.dev/glossary/rollback): Returning a service to its previous known-good version after a bad deploy.
- [Runbook](https://pagerless.dev/glossary/runbook): Written steps for handling a known kind of problem, so whoever is on call can act without deep context.
- [Severity](https://pagerless.dev/glossary/severity): A label for how bad an incident is, often SEV1 to SEV4, used to decide who responds and how fast.
- [SLA](https://pagerless.dev/glossary/sla): Service level agreement: a contract with users that includes consequences for meeting or missing the SLOs it contains.
- [SLI](https://pagerless.dev/glossary/sli): Service level indicator: a carefully defined quantitative measure of some aspect of service, such as the share of requests served successfully.
- [SLO](https://pagerless.dev/glossary/slo): Service level objective: a target value or range for an SLI, such as 99.9% of requests succeeding over 30 days.
- [Time-Sensitive notification](https://pagerless.dev/glossary/time-sensitive-notification): An iPhone notification level that breaks through Focus modes and notification summaries, but not the ring/silent switch.
- [Uptime](https://pagerless.dev/glossary/uptime): The share of time a service is available