On-Call Schedule

On-call responsibilities exist as informal agreements — 'I think Sarah handles pages on weekends' and 'Dave usually picks up alerts for the billing service.' There is no written schedule, no documented escalation path, and no formal rotation. When an alert fires at 2 AM and nobody responds, the VP of Engineering starts calling engineers' personal phones until someone answers.

None — AI cannot route incidents or optimize on-call workload because no on-call schedule records exist in any system.

An on-call schedule exists in PagerDuty or a shared calendar, but it is sparse and inconsistent. Some teams have rotations configured; others rely on a single person who is 'always on-call.' Escalation paths are undefined or point to people who left months ago. Override swaps happen via Slack DMs and are not reflected in the schedule. 'Who is actually on-call for this service right now?' often requires asking around rather than checking the tool.

AI can read the configured schedule, but it frequently does not reflect reality because overrides, swaps, and stale entries make the recorded schedule unreliable as a routing source.

On-call schedules are maintained in a standard tool with consistent practices — every team has a rotation, escalation paths are defined, and overrides are recorded. New hires are added to rotations during onboarding. But the schedule records are isolated from other operational context — there is no link between who is on-call and which services they are responsible for, what their expertise covers, or how fatigued they are from recent pages.

AI can reliably route alerts to the correct on-call engineer based on the schedule. Cannot optimize routing based on engineer expertise, recent page load, or service-specific knowledge because the schedule lacks this contextual metadata.

On-call schedules are comprehensive operational records. Each rotation links to the specific services covered, the engineers' expertise areas, and the escalation chain with response time expectations. Historical on-call burden metrics (pages per shift, hours engaged, after-hours frequency) are tracked per engineer. A manager can query 'show me the on-call burden distribution across the platform team for the last quarter, broken down by severity and time of day' and get a documented, accurate answer.

AI can optimize on-call rotations for fair burden distribution, match page routing to engineer expertise, and predict schedule gaps (holidays, team changes). Cannot yet autonomously redesign escalation policies because organizational reporting structures and political sensitivities require human judgment.

On-call schedules are formal entities in a workforce operations ontology. Each schedule has typed relationships to service domains, engineer skill profiles, coverage constraints, and organizational policies. An AI agent can ask 'generate an optimal on-call rotation for Q2 that ensures tier-1 payment services always have a payments-certified engineer on primary, maintains fair burden distribution, and accounts for planned PTO' and produce a valid, constraint-satisfying schedule.

AI can autonomously generate, validate, and optimize on-call schedules within the formal workforce model. Can produce constraint-satisfying rotations that balance fairness, coverage, and expertise. Human approval is needed for schedules that affect work-life balance policies.

On-call schedules are self-maintaining operational records. Team composition changes automatically adjust rotations. PTO submissions trigger schedule rebalancing. Incident pattern analysis suggests escalation policy updates. New service launches auto-assign on-call coverage based on the team's service ownership and expertise profiles. The schedule generates its own optimal configuration from workforce and operational signals.

Can autonomously maintain, optimize, and evolve on-call schedules in real-time based on workforce composition, incident patterns, and operational requirements without human schedule administration.

Ceiling of the CMC framework for this dimension.