An on-call program is more than a schedule — it's a system for ensuring the right person responds to incidents at any hour, with the tools and context they need, without burning out the people doing the work.
Choose an on-call model that fits your team size and incident volume:
Follow-the-sun — Teams in different time zones cover their daylight hours. Handoff happens at shift boundaries. Ideal for global organizations with 24/7 staffing.
Weekly rotations — One person carries the pager for a full week. Simple to manage but intense during high-incident periods. Best for teams with low to moderate incident volume.
Daily rotations — Each day has a different primary and secondary. More complex scheduling but spreads the cognitive load. Best for teams with high incident volume.
Pooled on-call — A team of designated responders, not the whole engineering organization. Dedicated on-call specialists who handle all incidents during their shift.
Every shift should have at least two people:
Primary — First responder. Handles initial triage, containment, and incident coordination. If they can't resolve within the time budget, they escalate.
Secondary — Backup responder. Available if primary is already engaged with another incident. Handles the next incident while primary works the current one.
On-call is disruptive and stressful. Compensate fairly:
The best compensation model depends on your company's culture and budget. Communicate it clearly and review it annually.
Configuration-as-code (CaC) treats your on-call tooling configuration as version-controlled, reviewable, and deployable artifacts — just like your application code. This eliminates manual configuration drift and makes changes auditable.
PagerDuty configuration covers three main areas:
Escalation policies — Define the order and timing of notifications. A standard policy might have three levels: primary (immediate), secondary (5 minutes), and on-call manager (10 minutes). Each level specifies who is notified and how.
Services — Each monitored service maps to a PagerDuty service with its own escalation policy, alert grouping rules, and severity mappings. Services are the unit of ownership and alert routing.
Alert routing — Rules that route incoming events to the correct service based on source, severity, or custom fields. This ensures alerts reach the right team without manual intervention.
OpsGenie follows a similar structure with different terminology:
Escalation policies — Multi-tier escalation with configurable delays and notification methods. OpsGenie supports round-robin, random, and ordered notification within each tier.
Schedules — Define who is on-call and when. OpsGenie supports follow-the-sun, weekly, and custom rotation patterns. Schedules are referenced by escalation policies.
Routing rules — Use alert tags, priority, and source fields to route alerts to the correct team, schedule, or escalation policy. Rules are evaluated in priority order.
The YAML configs in this product map directly to Terraform resources:
resource "pagerduty_escalation_policy" "platform" {
name = "Platform Engineering"
rule {
escalation_delay_in_minutes = 5
target {
type = "schedule_reference"
id = pagerduty_schedule.primary.id
}
}
}Store the YAML configs in a dedicated repository, create a Terraform module that reads them, and deploy changes through your regular CI/CD pipeline.
Get the full On-Call Management Kit and unlock everything.
Get the complete guide with every chapter unlocked, including code samples, diagrams, and best practices.
Access all interactive tools with complete data, all workload profiles, and the full scenario library.
Downloadable source code, configuration files, and working examples from every chapter.
Free updates for life. Every new chapter, tool, and improvement included.