PagerDuty Foundational Practitioner common mistakes
PagerDuty Foundational Practitioner · Understand the traps and how to avoid them.
Treating a PagerDuty service as the alerting rule itself, so they configure escalation policies and integrations on a service but never define what actually creates an incident, then cannot answer questions about how an alert becomes an incident.
Candidates coming from monitoring tools assume the service 'is' the monitor. In PagerDuty, a service is the routing and ownership boundary; incidents are created by integrations, Event Orchestration, or the Events API v2. The mental model is inverted, so questions about the incident lifecycle expose the gap.
What to do instead
Draw the chain explicitly: signal source → integration or Events API → service → escalation policy → on-call responder. For each service in a practice scenario, write down which integration creates incidents and which escalation policy owns them. Test yourself by describing what happens between an alert firing and a responder being paged, naming each object.
Confusing escalation policy levels with notification rules, and answering that adding a level changes how an individual is contacted (push, SMS, phone) rather than when the next responder is engaged.
Both live under 'who gets notified', so the terms blur. Escalation policy levels define the timeout and the target (user, schedule, team) for escalation; notification rules on a user profile define contact methods and delays. Candidates who never configured both in a sandbox merge them.
What to do instead
Memorise the split: escalation policy = escalation timing and target order; notification rules = per-user contact method and delay. Build one policy with two levels and one user with two notification rules, then trace a hypothetical unacknowledged incident minute by minute and note which object fires at each step.
Assuming acknowledging an incident stops all further escalation permanently, or that resolving it is required before the next alert on the same service can page anyone.
In many ticketing systems 'acknowledge' closes the loop. In PagerDuty, acknowledgement stops the current escalation for that incident, but a new trigger creates a new incident, and unresolved incidents can still escalate if the policy is configured that way. Candidates over-generalise from one workflow.
What to do instead
Study the distinct states (triggered, acknowledged, resolved) and what each does to escalation. Practise a scenario where an incident is acknowledged and then re-triggers, and one where a second alert arrives on the same service. Write the expected paging behaviour for each before checking documentation.
Treating Event Orchestration rules as simple filters that drop noise, and missing that rules can set severity, route to a different service, suppress, or extract fields, then mis-answering questions about precedence and rule ordering.
The word 'orchestration' sounds like routing only. In practice the ruleset evaluates top-down with conditions and actions, and the first matching rule wins, so ordering changes outcomes. Candidates skim the feature page and assume a flat filter list.
What to do instead
Learn the rule anatomy: conditions, actions (route, severity, suppress, annotate, extract), and evaluation order. Build a three-rule ruleset in a trial account where rule order changes the destination, then predict and verify the outcome. Be able to state what happens when no rule matches, including the global ruleset fallback.
Confusing alert grouping and suppression with deduplication, so they answer that suppression merges duplicate alerts into one incident when it actually prevents an alert from creating an incident at all.
All three reduce noise, so the terms collapse under exam pressure. Deduplication uses a dedup key to attach alerts to an existing incident; grouping bundles related alerts; suppression drops the alert entirely. Candidates who only read summaries cannot separate the effects.
What to do instead
Make a comparison table with columns: mechanism, input used (dedup key, grouping key, condition), effect on incident count, and whether the alert is still visible in the timeline. Populate it from hands-on tests with the Events API, sending alerts with the same and different dedup keys and observing incident counts.
Assuming a single global on-call schedule covers all time zones, and answering schedule questions without accounting for schedule layers, overrides, and rotation handoff times.
Schedules look like a simple calendar in the UI. Real configurations use layers for follow-the-sun coverage, overrides for swaps, and handoff times that determine who is paged at a boundary. Candidates who never built a multi-layer schedule miss the boundary behaviour.
What to do instead
Create a two-layer schedule spanning two time zones with a defined handoff, add an override, and inspect who is on call at times just before and after the handoff. Learn how overrides interact with layers and how a gap in coverage produces no responder. Practise reading a schedule's rendered timeline rather than its summary.
Treating automation actions and runbook automation as interchangeable with alert routing, so they answer that an automation action can change which service receives an alert rather than executing a task in response to an incident.
Both are 'automation' in the product surface. Automation actions run against an incident (for example, triggering a job or a webhook) after it exists; routing decisions happen earlier in orchestration. Candidates group by feature name instead of by lifecycle stage.
What to do instead
Place every automation feature on the incident lifecycle: pre-incident (orchestration, suppression), incident-time (automation actions, runbook steps), post-incident (postmortems, analytics). For each, note the trigger and the actor. Then answer practice questions by first asking 'at what stage does this run?' before recalling the feature.
Answering questions about Paige, PagerDuty's SRE agent, as if it were a general-purpose chatbot, attributing to it actions like acknowledging incidents or editing escalation policies on its own.
Paige is new and marketed alongside AI assistants elsewhere, so candidates import assumptions from other products. Its role is to surface context and assist with investigation and reliability work inside the platform, not to autonomously operate incident response.
What to do instead
Write a one-paragraph description of Paige's scope from current product documentation: what it summarises or surfaces, where it appears in the product, and what it explicitly does not do. Keep it separate from automation actions and from Event Orchestration in your notes, and re-read it before the exam because this area changes quickly.
Assuming a webhook or integration is bidirectional, so they answer that a PagerDuty incident update automatically writes back to the source monitoring tool without a separate configuration.
Integrations are described as 'connecting' tools, which implies two-way sync. Most inbound integrations only create incidents; outbound updates require webhooks, extension configurations, or API calls. Candidates who never wired a webhook assume symmetry.
What to do instead
Classify each integration you study as inbound-only, outbound-only, or bidirectional, and note the mechanism for each direction (Events API, webhooks, extensions, REST API). Practise creating an incident via the Events API and then configuring a webhook subscription to observe the outbound event, so the asymmetry is concrete.
Memorising REST API endpoint paths and payload fields instead of understanding the resource model and authentication, then failing questions that ask which object to query or how to authenticate a request.
Developer-platform questions reward model knowledge, but candidates study API references as lists of URLs. When a question describes a goal rather than an endpoint, they cannot map goal to resource. They also miss the distinction between API key types and OAuth.
What to do instead
Learn the resource graph: services, escalation policies, schedules, users, incidents, and their relationships. For authentication, be able to state which key type suits which use case and where it is scoped. Practise by describing, in words, the sequence of API calls needed to find who is on call now for a given service, without looking up endpoint paths.