English for PagerDuty On-Call

PagerDuty’s terminology — escalation policies, urgency, acknowledgment — is what an on-call rotation actually runs on, and misusing a term during a live page (saying “resolved” when you mean “acknowledged”) can genuinely confuse who’s responsible for what. This guide covers the vocabulary precisely.

Key Vocabulary

Escalation policy — the ordered chain of responders (primary on-call, then secondary, then a manager) that PagerDuty works through if a page isn’t acknowledged within a configured time window. “The escalation policy pages the primary first, and if there’s no acknowledgment within ten minutes, it automatically escalates to the secondary on-call.”

Urgency — the severity classification (high or low) assigned to an incident that determines whether it triggers an immediate page or a lower-priority notification, configured per service and per alerting rule. “We downgraded this alert’s urgency to low — it’s worth knowing about, but it doesn’t need to wake anyone up at 3am.”

Acknowledge — the action a responder takes to signal they’ve seen an incident and are working on it, which pauses further escalation but does not mean the underlying issue is fixed. “I acknowledged the page so it stops escalating to Priya, but I haven’t actually resolved anything yet — still investigating.”

Resolve — the action marking an incident as fully addressed, distinct from acknowledging it; resolving too early on a still-ongoing issue causes the alert to potentially re-trigger and confuses the incident timeline. “Don’t resolve it yet — the error rate dropped, but we haven’t confirmed the root cause, and I’d rather keep it open until we’re sure it’s not going to recur.”

On-call handoff — the scheduled transition of on-call responsibility from one person to the next, ideally accompanied by a verbal or written summary of anything still in progress. “At the handoff, I flagged the ongoing intermittent 500s on the payments service — nothing paged yet, but it’s worth watching over the next rotation.”

Common Phrases

• “Has this been acknowledged, or is it still escalating?”
• “What urgency is this alert set to — should it actually be paging someone right now?”
• “Are we ready to resolve this, or is it still under investigation?”
• “Who’s next in the escalation policy if this doesn’t get acknowledged in time?”
• “Is there anything to flag at the handoff, even if it hasn’t paged yet?”

Example Sentences

Acknowledging a page in a team channel: “Acknowledging now — looking into the elevated error rate on checkout. Will update here within fifteen minutes.”

Explaining an escalation policy change: “We added a secondary on-call to the escalation policy after last month’s incident, where the primary was unreachable for twenty minutes before anyone else got paged.”

Writing a handoff note: “Handing off with one open item: intermittent latency spikes on the search service, not yet urgent enough to page, but keep an eye on the dashboard over the next shift.”

Professional Tips

• Use acknowledge and resolve precisely and never interchangeably — acknowledging silences escalation, resolving closes the incident, and mixing them up creates confusion about whether an issue is actually fixed.
• Set urgency deliberately per alert type and revisit it after incidents — an alert that keeps paging for something non-urgent trains people to ignore pages, which is dangerous.
• Reference the escalation policy explicitly when proposing on-call structure changes — “someone should get paged eventually” isn’t a policy; a defined chain with timeouts is.
• Always give a handoff summary, even a short one, for anything still unresolved — silence at a handoff is how a minor lingering issue becomes the next shift’s surprise incident.

Practice Exercise

1. Write a sentence explaining the difference between acknowledging and resolving an incident.
2. Describe an escalation policy with a primary, secondary, and timeout.
3. Write a short handoff note for an ongoing but non-urgent issue.

Navigating Nuance: Handling Feedback & Requests

Let’s be honest – even in English, communicating effectively about code can feel incredibly nuanced. It’s not just about what you say, but how you say it, especially when dealing with feedback or requests from colleagues. As a developer, your ability to articulate issues clearly and respectfully is paramount, particularly when collaborating on projects and reporting incidents within PagerDuty. Many non-native speakers find the directness of some Western communication styles challenging – a suggestion for “rework” can feel like criticism, and simply stating a problem might not convey the urgency or context needed for a rapid resolution.

One common scenario is receiving a comment during a code review. Imagine you’ve submitted a pull request for a new feature in your project. A senior engineer leaves a comment: “This section could benefit from some refactoring; consider using more descriptive variable names to improve readability.” Now, a literal translation might focus on the technical aspects of refactoring, but the intent is about clarity and maintainability. Responding simply with “Okay” doesn’t address the underlying concern. A better response would be, “Thanks for pointing that out! I agree; using more descriptive names will definitely improve readability. I’ll update it to follow those guidelines.” Notice how we acknowledged the feedback, expressed agreement, and outlined a concrete action. This demonstrates respect and collaboration. Similarly, when requesting assistance from another team member via Slack – perhaps needing clarification on an incident – phrasing your request carefully is key. Instead of saying “Fix this,” try “Could you take a look at this incident? I’m struggling to understand the root cause and need some guidance on how best to proceed.”

Another frequent situation arises when escalating an incident within PagerDuty. The initial description might be brief, but as the issue evolves, precise language becomes critical. Using the correct urgency level – Low, Medium, or High – isn’t just a technical classification; it’s a communication signal to your team. A clear and concise update like: “Incident 12345 - System outage impacting user authentication. Initial investigation suggests potential database connectivity issue. Requesting immediate attention (Priority High) due to significant user impact.” demonstrates the seriousness of the situation without resorting to overly dramatic language.

# Example PagerDuty CLI command for creating an incident update:
`pd incident update 12345 --title "Database Connectivity Issue" --description "Further investigation reveals high latency impacting authentication services.  Escalating to Level 2 support." --severity High`

Finally, remember that a “clean handoff” – the process of fully documenting an incident and transferring it to another on-call team – relies heavily on precise communication. A detailed summary outlining the problem, steps taken, and outstanding questions is vital for ensuring a smooth transition.