resolved
PagerDuty
pagerduty.com/schedules#{schedule-id}
landed in 38msBookSlash for PagerDuty · IT
On-call rotations live in PagerDuty; the URLs people actually need during an incident live in five other tools. BookSlash gives each one a name the rotation memorises — and PagerDuty escalation messages can include the slug so engineers reach the runbook in one keystroke.
resolved
PagerDuty
pagerduty.com/schedules#{schedule-id}
landed in 38msother shortcuts you might save
Suggested slug patterns
Battle-tested shortcut conventions for PagerDuty, with notes on why each one survives the URL changes that break personal bookmarks.
Currently on-call schedule for the team.
Every "who’s on-call?" question vanishes once this slug exists. The destination updates as the rotation rolls.
Escalation policy for the active service.
On-call engineers need it during a SEV; the URL is buried.
Active incidents view.
The status banner of the engineering org. Pairs with b/oncall for full incident context.
Runbook for the paged service (lives in your wiki, not PagerDuty).
PagerDuty alert payloads include this slug; on-call lands on the runbook in two keystrokes.
SEV-1 incident playbook / war-room template.
When SEV-1 hits, every engineer needs to remember exactly one URL.
Common workflows
Configure PagerDuty alert messages to include "Open b/runbook-{{service.name}}" — the runbook lives outside PagerDuty (eng-wiki, Notion, or a BookSlash board). On-call engineers go from page → b/runbook-checkout → mitigation in two keystrokes, even from their phone.
b/sev1 lands the incident commander on a board template (or PagerDuty playbook page) with status, timeline, decision log, and post-mortem skeleton. Same canvas for every SEV-1 — see /use-cases/incident-response.
Each new on-call shift inherits the same six slugs: b/oncall, b/escalate, b/runbook-<their-service>, b/dash-<service>, b/incidents, b/sev1. No tribal-knowledge handoff; the rotation is a finite, documented set of shortcuts.
With and without
Without shortcuts
Every engineer has their own bookmark for the on-call schedule. Escalation policies live in PagerDuty; runbooks live in Notion; dashboards live in Datadog. SEV response includes 90 seconds of finding the right links.
With BookSlash
b/oncall, b/escalate, b/runbook-<service>, b/dash-<service>, b/sev1. Five slugs cover the full incident path. PagerDuty payloads carry the slug so the engineer reaches the runbook in one keystroke from their phone.
Related integrations
Frequently asked
Edit your escalation policy in PagerDuty → Notifications → Custom message template. Add "Runbook: b/runbook-{{service.name}}" to the alert body. The slug renders as plain text in the alert; the engineer’s phone keyboard can dictate it directly into a browser.
It shows the URL of your PagerDuty schedule, which PagerDuty keeps current as the rotation rolls. The slug never changes; the underlying display does.
No. BookSlash is the link layer; PagerDuty is the paging layer. They complement each other: PagerDuty wakes the engineer, the slug in the page payload tells them where to go.
Namespace per team: b/oncall-eng, b/oncall-platform, b/oncall-data. Each team’s rotation has its own slug; the b/ pattern stays consistent across the org.
Start with one team. Roll out when it sticks.
2,400+ teams reach every important destination in their stack with a single keystroke. Save the first slug in 30 seconds.
Free for personal use · No credit card · 14-day team trial