Skip to main content

​
Overview

On-call schedules are living configurations that evolve as teams grow, coverage changes, and real-world situations arise. While schedules define who is responsible at any given moment, Rootly is designed so that edits to schedules are safe, auditable, and non-destructive. When you update a schedule—whether by adding users, creating overrides, or temporarily pausing paging—Rootly ensures that historical records remain intact. Past incidents, alerts, and timelines continue to reflect exactly who was on call at that moment in time, while your changes only apply going forward. This page walks through how to confidently edit schedules after they’ve been created, including managing overrides and pausing schedules without deleting them.

​
How schedule changes work

Any changes made to a schedule only affect future shifts.
Rootly intentionally prevents edits from modifying past on-call history to preserve accurate audits, incident timelines, and compliance records.

​
Required permissions

Only users with the following On-Call roles can create, edit, or delete schedules:
  • Admin
  • User
Users with Observer access can view schedules but cannot make changes.

​
How Rotation Order Works

Members of a rotation hold numbered positions, 1 through N, and Rootly cycles through them in that order. Position is what determines whose turn is next — not join date, not alphabetical order. Two consequences worth knowing before you edit a rotation:
  • Removing a member renumbers the rest. Everyone below moves up a position. This is about position numbering, not coverage — removing someone does not fill the on-call hole their absence creates. Removing the person at position 2 of 5 leaves four members at positions 1 through 4, and the person who was at 3 now takes the second turn in the cycle.
  • Reordering changes who is next. Positions are the schedule, so moving someone up moves their turn forward.

​
What Happens to Shifts When You Edit a Rotation

Editing a rotation regenerates its future shifts. Regeneration starts from the beginning of the most recent turn, not from the moment you clicked save, so the cycle stays aligned rather than restarting mid-stride. The shift that is in progress right now keeps its original end time. Whoever is on call stays on call until the handoff they expected, even though the shifts after it have been rebuilt. An edit made during someone’s shift does not cut that shift short or hand the pager over without warning.
Past shifts are never regenerated. Incident timelines and audit records continue to show who was actually on call at the time.

​
Deactivating a User

Deactivating a user in Rootly has effects across on-call that are worth understanding before you do it — especially at the end of someone’s last day, when there may not be time to react to the consequences. Deactivation does all of the following:
  1. Deletes their future overrides. Any coverage they had agreed to take is removed, not reassigned. Shifts they were covering revert to whoever the rotation would otherwise put there.
  2. Removes them from every rotation. Whoever was next in the cycle after them stays next — removal doesn’t skip or duplicate a turn. The position numbers themselves get tidied up the next time the rotation is saved, not necessarily at the instant you deactivate.
  3. Regenerates affected shifts, typically within about five seconds.
  4. Can open a coverage gap. If nobody else is available for the shift they were covering, the schedule now has a hole where they used to be.
  5. Flags a replacement in the rotation editor the next time it’s opened, if one is still needed.
Point 1 is the one that surprises people. If a departing teammate had agreed to cover a shift next week, deactivating them silently gives that shift back to the rotation — and the person it lands on may not know they have it.Check for future overrides before deactivating, and reassign anything that matters to a named person first. Overrides are listed under Managing Overrides on this page.
After deactivating, open the schedule and look at the gap indicators before you close the tab — opening the page is what checks for gaps; deactivating on its own does not. Gap detection surfaces the holes; it does not fill them.

​
Managing Overrides

Overrides are the safest and most flexible way to handle short-term coverage changes. Instead of editing a rotation—which can affect many future shifts—an override temporarily assigns a specific shift to a different user while leaving the underlying schedule unchanged. Common use cases include vacations, sick days, training, or one-off coverage swaps. Overrides always apply to individual users and automatically take precedence over rotation-based shifts. Rootly enforces guardrails to ensure overrides do not overlap or create paging conflicts.

​
Reassigning or Reverting an Override

To manage an override, navigate to On-Call → Schedules and open the schedule you want to modify. Shifts that are currently overridden are clearly marked with an Override label, making it easy to distinguish them from standard rotation shifts.

​
Reverting (Deleting) an Override

Reverting an override deletes the override entirely and restores the shift to its original assignee based on the schedule’s rotation logic. There is no separate “Delete” action for overrides — Revert is the deletion mechanism. Use it whenever you want to cancel an override you created in error, or once a temporary coverage change is no longer needed. Select the overridden shift, then choose Revert to original. The shift will immediately return to the user originally assigned by the rotation.
Overrides can also be reverted from the On-Call Shifts page.
All override actions—including creation, reassignment, and reversion—are logged and auditable.

​
Reassigning an Override

If coverage needs to change again, you can reassign an existing override to a different user. After selecting the overridden shift, choose the new user who should cover it and click Create Override. Rootly validates the change automatically, ensuring the override does not overlap with other overrides or violate paging rules. Overrides cannot be assigned to another schedule and must always map to a single user. This ensures accountability and predictable paging behavior.

​
Pausing a Schedule

Sometimes a schedule needs to be temporarily disabled without being deleted. This might happen during a service deprecation, team reorganization, or a period where paging should be suppressed. In Rootly, schedules do not page responders on their own. Paging only occurs when a schedule is referenced by an Escalation Policy. This makes pausing a schedule both simple and reversible. To pause a schedule, remove it from any escalation policies that reference it. The schedule itself remains fully intact and can be reactivated later by re-adding it to an escalation policy.

​
How to Pause a Schedule

1

Open Escalation Policies

Navigate to On-Call → Escalation Policies.
2

Open the Policy

Open the escalation policy that includes the schedule.
3

Remove the Schedule

Edit the policy and remove the schedule from the Who do we notify? section.
4

Save

Save the escalation policy.
Once removed, the schedule will stop paging immediately, but no configuration or historical data is lost.

​
Best Practices

When editing schedules, use overrides for short-term changes and reserve rotation edits for long-term structural updates. Pausing schedules by removing them from escalation policies is safer than deleting them outright, especially if you may need them again in the future. Regularly reviewing schedules after team changes helps prevent stale paging paths and ensures alerts always reach the correct responder.

​
Frequently Asked Questions (FAQs)

No. Overrides only apply to future shifts. Rootly never rewrites historical on-call data, ensuring incident timelines and audits remain accurate.
No. Overrides must always be assigned to an individual user. Schedules cannot be used as override targets.
Rootly records the change in the audit log and can notify responders through integrated channels such as Slack, ensuring visibility into coverage changes.
Remove the schedule from all associated escalation policies. This pauses paging while preserving the schedule for future use.

Schedules

The parent concept — schedules are what these edit / pause / delete operations act on.

Escalation Policies

Removing a schedule from every escalation policy is how you pause it without deleting it.

Request Coverage

A lighter-weight alternative to editing the schedule for one-off swaps.