Glossary
Look up the terms used for Status monitoring, incident response, and administration.
This glossary defines terms used in Status.
| Term | Plain-language meaning |
|---|---|
| Acknowledge | Record that a responder has taken responsibility for an incident. It does not resolve or assign the incident. |
| Agent or worker | A separate Status process that performs monitor checks and sends results back to the Status application. A private agent belongs to one organization. |
| Alert channel | An external destination—such as email, webhook, chat, or PagerDuty—that receives selected incident events. |
| API key | A secret credential used by scripts or integrations. It is not a person's sign-in password. |
| Component | A customer-facing service or feature shown on a status page, such as Website or Payments. One component can use one or more monitors for health. |
| Environment | A label such as production or staging used to classify and filter monitors and related information. Changing the selector filters the view; it does not move records. |
| Error budget | The amount of failed service a service-level objective still allows within its window before the target is missed. |
| Escalation policy | An ordered list of paging targets and per-step wait times. Status steps through the policy until an incident is acknowledged or resolved. |
| Failure confirmation | The amount of sustained failure Status requires before changing a monitor to down. It reduces alerts from brief errors. |
| Incident | The shared record of a service problem, including its severity, public updates, private response work, ownership, and timeline. |
| Maintenance window | A planned period when selected monitor failures are expected and checks are suppressed. It is different from indefinitely pausing a monitor. |
| Monitor | The saved description of what Status checks, where it checks from, how often it runs, and what counts as success. |
| Notification | A message delivered to a person's in-app inbox, browser, or another configured channel because an event matched its targeting rules. |
| Objective (SLO) | A target placed on one monitor—availability or latency—with a window and a budget for failure. Burn alerts page responders when the budget is spent too fast. |
| Organization | An isolated workspace containing its own monitors, incidents, members, status pages, and settings. Switching organizations changes which workspace you are using. |
| Pending | A monitor state meaning Status does not yet have enough accepted information to decide whether the target is up or down. The monitor list shows this state as Waiting. |
| Recovery confirmation | The amount of sustained success required before a down monitor returns to up. |
| Region | A named worker location used to run checks from a particular place or network. |
| Role | A person's permission level in an organization: viewer, member, admin, or owner. |
| Runbook | Instructions your organization maintains for diagnosing or recovering a service. A monitor can link to one. |
| Severity | An incident's impact level: minor, major, or critical. Organizations should define their own examples for consistent use. |
| Status page | A page that communicates selected component health, incidents, maintenance, and history to an audience. |
| Subscriber | A person or endpoint that confirmed a status-page subscription and selected which published events or components to follow. |
| Suppressed | Prevented from changing health or generating expected incident noise, usually because of maintenance, a schedule, or an unhealthy dependency. The result may still exist in history. |
| Taxonomy | Shared tags and folders used to classify monitors. Environment and ownership fields are related classification metadata. |
| Timeline | The attributed, ordered history of changes and events on an incident or maintenance window. |
| Workbench | A safe place to run an editable monitor draft without changing the saved monitor, production health, or incident state. |