Whoever's turn it is, escalation already knows

A rotation that's computed, not maintained

A schedule is a plain, repeating handoff: add the organization members who take a shift, in the order they'll rotate, and set how often the handoff happens. Every rotation_length_days, on-call moves to the next person in the list, wrapping back to the start once it reaches the end, computed fresh from a start date rather than read off a calendar anyone has to keep updating by hand.

That's a deliberately simple shape, the same "ship the useful core first" call this app already made for escalation policies themselves: a plain repeating rotation, not an arbitrary layered-shifts calendar engine with its own conflict resolution to reason about.

Overrides for the one-off cases

PTO and illness happen without warning the rotation. An override is a one-off substitution for a specific window, and its own user doesn't have to already be a rotation member: covering for someone can mean bringing in anyone else in the organization, not only another already-scheduled person.

Any override covering a given moment wins outright over whatever the computed rotation would otherwise say, for its own window only; once it ends, the rotation picks back up exactly where it would have been anyway, with nothing to manually restore afterward.

Escalation that pages the right person automatically

An escalation policy has two steps, primary and backup, and each one either resolves through an on-call schedule or is a hand-typed contact, never both. A schedule-driven step is resolved fresh at the moment it actually fires, not once when the policy was first configured, since who's on call can genuinely change between the primary page and the backup one going out minutes later.

If the primary step isn't acknowledged within the policy's own escalate_after_minutes window, the backup step fires next, on whichever channel that step is configured for. There's no separate "recovered" notification to wait on either: acknowledging is a single link in the alert itself, and it stops the escalation from ever reaching its backup step at all.

Enterprise plan only

Enforced at the model layer, the same unbypassable pattern every other gated feature in this app uses (SSO, uptime monitoring, API access): an escalation policy can't be saved for an organization whose plan doesn't include it, regardless of which path in the app tries to create one. A schedule on its own can be built on any plan; it's simply of no use until a policy can actually reference it.