On-Call Schedule Cleanup: Remove Rotations After Ownership Moves

On-Call Schedule Cleanup: Remove Rotations After Ownership Moves starts with a pager route that still points at the team that used to own the service. The on-call rotation may look quiet, but quiet is not the same as unused. It can still support a rare workflow, a contract, a rollback path, or an owner who no longer sits near the team doing the cleanup.

Use this note when you need to reduce stale software surface area without turning deletion into the first real test. The useful result is a small decision record: current owner, current purpose, evidence reviewed, reversible first step, caveats, and the rule that prevents the same on-call rotation from returning.

What makes this cleanup risky

The risk is not age. The risk is losing a dependency that is visible only during unusual conditions. In on-call schedule cleanup, the review should start by naming the exact behavior the on-call rotation still enables and the exact behavior that has replaced it.

Review area	What to inspect	Cleanup signal
Current owner	Team, service, data owner, or support path	Someone can approve a keep or remove decision
Runtime evidence	page history, escalation timeouts, service catalog owner, runbook links, access checks, and business-hours rehearsal	Recent use is absent or explained
Replacement path	current service owner route	The new path handles the same real cases
Rollback or history	Backup, audit, archive, or recreation plan	A wrong decision is recoverable
Creation path	How new items are created	A prevention rule can stop recurrence

A cleanup candidate with no owner should not be treated as safe. It should be treated as an ownership bug that must be resolved before the final removal.

Evidence checks that fit the subject

Collect several signals before acting:

• Inspect page history, escalation timeouts, service catalog owner, runbook links, access checks, and business-hours rehearsal.
• Confirm the replacement path, not just the absence of recent edits.
• Review the longest business, reporting, incident, or customer cycle that could still use the on-call rotation.
• Ask the owner to choose keep, narrow, archive, disable, remove, or investigate.

A focused review sample can keep the conversation concrete:

route: checkout-latency
old_schedule: core-api-primary
new_owner: payments
decision: move after runbook rehearsal

Treat the output as a candidate list, not a deletion command. It proves one slice of behavior and must be paired with ownership, dependency review, and a rollback plan.

Prefer a reversible first move

Good cleanup usually happens in stages. First stop creating new on-call rotation records or references. Then narrow the scope, disable the stale path, or archive the visible surface while watching for unexpected use. Remove only after the waiting window matches how the system is actually used.

Do not rush when the on-call rotation touches security response, customer commitments, billing, compliance, incident recovery, or low-frequency operational work. Also slow down when the replacement changed semantics rather than only names; similar labels can hide different behavior.

Prevention rule

service ownership transfer should include alert route, runbook, escalation policy, access, and catalog updates. Add the rule where the on-call rotation is created, not only in a cleanup spreadsheet. The next cleanup should begin with owner and sunset context already attached.

Key takeaways

• Stale on-call rotation cleanup needs evidence about use, ownership, replacement, and reversibility.
• Recent silence is helpful, but it is not enough by itself.
• The best first move is usually narrowing, disabling, or archiving before final removal.
• Prevention belongs in the creation path so the same stale item does not return.