PagerDuty Foundational Practitioner flashcards

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

Incident lifecycle states

An incident moves from Triggered to Acknowledged to Resolved. Triggered means notifications are firing; Acknowledged stops escalation; Resolved closes the record and enables postmortem work.

Escalation policy levels

Each level lists targets and a timeout. If no target at level one acknowledges within the timeout, the policy advances to level two and continues until someone acknowledges or the policy ends.

Service configuration components

A service combines one escalation policy, one or more integrations with routing keys, optional support hours, urgency rules, alert grouping, auto-pause, and auto-resolve settings that shape incident behavior.

Urgency versus priority

Urgency is high or low and controls notification timing, since low-urgency incidents may wait. Priority is a separate triage field used for ordering, reporting, and workflow conditions.

Schedule layers and overrides

Layers stack in order, and the first layer containing a user determines on-call status. Overrides replace the computed rotation for a specific user and time range, taking precedence over layers.

Incident merge behavior

Merging folds duplicate incidents into one primary incident. Alerts from the merged incidents are re-parented to the primary, and responders work a single thread instead of several.

Stakeholder updates

Status updates posted to an incident notify configured subscribers such as stakeholders or status pages. They are separate from responder notifications and do not change escalation or acknowledgement state.

Dedup key function

The dedup_key groups events into a single alert. Reusing a key updates the open alert rather than creating a new one, and omitting it lets PagerDuty generate a unique value.

Events API v2 fields

A trigger event carries routing_key, event_action, dedup_key, and a payload containing summary, source, severity, and custom_details. Acknowledge and resolve actions reuse the same dedup_key.

Alert to incident grouping

Alert grouping settings decide whether multiple alerts on a service collapse into one incident. Time-window grouping clusters alerts arriving close together; grouping type sets the rule applied.

Event Orchestration rule order

Global rulesets evaluate before service-level rulesets. A matching rule can route the event to a different service, suppress it, set severity, or extract values into variables for later rules.

Suppression rule effect

A suppression rule prevents matched events from creating or updating incidents. The event is recorded but stays silent, which reduces noise from known low-value alerts during expected conditions.

Intelligent alert grouping

Machine learning compares incoming alerts for similarity and clusters related ones into a single incident. Manual grouping instead uses explicit rules defined by the service owner.

Severity propagation

Events carry severity values of critical, error, warning, or info. That severity travels to the alert and can map to incident urgency or priority through service and orchestration rules.

Alert-to-incident ratio

This metric divides alerts received by incidents created. A high ratio means grouping and suppression are working; a low ratio suggests noise reaching responders as separate incidents.

Automation Action runner

Each automation action executes on a runner, either PagerDuty's cloud runbook automation or a self-hosted Rundeck-style node. The runner holds credentials and network reachability.

Incident Workflow structure

A workflow has a trigger, optional conditions, and ordered steps. Steps may be automation actions, manual tasks, or further workflow triggers, and they run in sequence after the trigger fires.

Workflow trigger types

Workflows start on incident created, priority updated, status changed, or manual invocation. Conditions narrow which incidents qualify, so a trigger can fire broadly while steps run selectively.

Pre- versus post-incident automation

Event Orchestration acts before an incident exists, routing and suppressing events. Incident Workflows act after creation, running remediation, enrichment, and notification steps against the incident.

Auto-pause and auto-resolve

Auto-pause suspends notifications when a linked alert stops firing, and auto-resolve closes the incident when alerts clear. Both reduce manual cleanup for self-healing conditions.

Maintenance windows

A maintenance window suppresses notifications for chosen services during a planned period. Incidents may still be recorded, but responders are not paged until the window ends.

MTTD and MTTA

Mean time to detect measures from event occurrence to incident creation. Mean time to acknowledge measures from creation to first acknowledgement, reflecting escalation policy and responder coverage.

MTTR definition

Mean time to resolve averages the interval from incident creation to resolution across a chosen population. It is usually segmented by service, urgency, and team to expose outliers.

Postmortem action items

A postmortem records contributing factors and assigns follow-up action items with owners. Tracking items to closure is what converts the review into reliability improvement rather than documentation.

Service ownership data

Analytics and escalation depend on accurate service records. A service lacking an owner or team assignment produces misrouted incidents and unreliable reporting by team and service.

Paige as SRE agent

Paige is PagerDuty's AI SRE agent. It summarizes incident context, surfaces related past incidents, and proposes next steps, drawing on the incident record and connected operational data.

Human accountability for Paige

Paige output is assistive. A human responder still owns acknowledgement, mitigation, and resolution, and should verify suggestions against current system state before acting.

Error budget tracking

Where service objectives are configured, dashboards show remaining error budget and burn rate. Budget exhaustion signals that reliability work should outrank further feature change.

Routing key purpose

The routing key, also called the integration key, identifies which service receives an event. It is passed as routing_key in Events API v2 requests and is unique per integration.

REST API v2 authentication

Requests use an Authorization header of the form Token token=YOUR_KEY plus a From header containing a valid user email. Missing or invalid From values cause authorization errors.

Webhook signature verification

Webhooks v3 sign payloads with a secret shared at subscription time. Compute the expected signature over the raw body and compare before trusting or parsing the delivered JSON.

Change Events API

The Change Events API records deployments and configuration changes against services. Those records correlate with incidents so responders can see whether a recent change preceded the failure.

Rate limit handling

API endpoints enforce rate limits and return HTTP 429 when exceeded. Clients should read the retry guidance, back off exponentially, and avoid retry storms during incidents.