Most teams run on-call using rotation-based schedules where responsibility shifts every few days or weeks. But some situations call for different models that change who responds based on time zones, expertise, or the type of incident that triggers. This guide walks you through six on-call models that work outside the standard rotation patterns.
Table of contents
1. Follow-the-sun on-call model
In a follow-the-sun model, on-call responsibility follows daylight hours around the globe. As the sun moves, so does the responsibility. Each regional team handles incidents during their working hours and hands off to the next region when their day ends.
Here is how it might look with three regional teams:
- Asia team covers their daylight hours and hands off to Europe
- Europe team takes over during their workday and hands off to the US
- US team handles incidents through their business hours and hands back to Asia
And the cycle continues from there.
Why choose Follow-the-sun on-call model
This on-call model protects sleep and personal time. No one gets paged at 3 AM because incidents always land during someone’s business hours. Many teams find this approach creates better work-life balance compared to traditional 24/7 rotations that sometimes wake people at odd hours.
It can also improve response quality. People handle incidents when they are fresh rather than groggy from interrupted sleep.
Challenges with Follow-the-sun on-call model
Clean 9-to-5 handoffs are harder to pull off than they look. When your team is spread across the globe, someone usually ends up starting a little earlier or finishing a little later to make the overlap work. That is generally a small trade-off, but it is worth being aware of before you set up the schedule.
Context gaps are probably the bigger challenge. If an incident triggers during the Asia shift and the Europe team takes over, the Europe responder might need more background to continue where things left off. The Asia person is likely asleep by then. You can work around this with solid handoff notes, but it takes discipline to keep them consistent.
To learn how to run smooth handoffs, check out our guide: handoff best practices for on-call teams
2. Shadow on-call model
In a shadow on-call model, you pair someone new to the rotation with a subject matter expert (SME). The new person takes the primary role, while the expert acts as backup.
Why choose Shadow on-call model
This on-call model often works well for onboarding new team members. They get hands-on experience with real incidents while knowing help is available when they get stuck.
It also distributes knowledge across the team. Experts can step back from handling every incident and focus on other work. The new responder learns by doing rather than just observing, which usually deepens their understanding of the system.
Challenges with Shadow on-call model
The trickiest part is usually agreeing on when to escalate. If the primary responder reaches out too quickly, they might not learn as much. If they wait too long, incidents can drag on longer than necessary. Finding the right balance often takes a bit of practice.
3. Follow-the-work on-call model
In this model, the person who ships a feature or updates a system becomes the primary on-call responder for it. This responsibility typically lasts for a short, set period after deployment.
Why choose Follow-the-work on-call model
Context often matters when incidents trigger. The person who built or recently updated a system usually knows it best. They often spot the problem faster and fix it with less investigation time.
It can also make ownership feel clear in the moment. There is no scramble to find who deployed the feature or updated the system last. The right person is already working on the issue.
Challenges with Follow-the-work on-call model
Information silos can sometimes form. If only one person supports a system, other team members might not learn how it works.
Workload can also become uneven. A person who ships frequently might end up on-call far more often than their teammates.
4. Night owl on-call model
The night owl on-call model assigns overnight shifts to specific people who prefer those hours or are hired for that schedule.
Why choose Night owl on-call model
You get dedicated coverage without interrupting anyone’s sleep. The rest of the team can disconnect at night knowing someone is available to respond.
It can also work well when overnight incidents follow predictable patterns. A dedicated night person usually makes more sense than spreading that responsibility across the entire team.
Some people are naturally more productive at night. If your team has someone who prefers those hours, the night owl model is worth considering.
Challenges with Night owl on-call model
The night team can sometimes drift apart from the day team. They might miss architectural discussions or context about recent changes. Keeping everyone connected usually requires intentional communication efforts.
Knowledge gaps can also develop over time. The night person might not have full context on what shipped during the day. This can slow down response when they encounter something unfamiliar.
5. VIP on-call model
In a VIP model, certain customers get special on-call treatment. You might have a dedicated on-call rotation for enterprise customers while standard customers follow the regular rotation.
Why choose VIP on-call model
Some customers pay for premium support. A separate rotation often makes it easier to meet their SLAs without affecting response times for others.
It also lets you assign specific engineers to high-value accounts. These customers usually have complex setups. You can match them with someone who has deep expertise and can troubleshoot quickly.
Challenges with VIP on-call model
Multiple on-call rotations create more complexity. You’ll need to route incidents based on customer tier.
With Spike, you can set up Alert Rules to automatically route incidents to the right rotation. Learn more →
It can also create mixed feelings within the team. Engineers not in the VIP rotation might feel their work is valued differently. Managing this perception usually takes some effort.
6. Red button on-call model
This model reserves subject matter experts (SMEs) for critical incidents only. They get paged for severe outages or emergencies. Regular incidents go through the standard rotation.
Why choose Red button on-call model
It keeps someone with deep expertise available for when things truly break. They focus their energy on problems that actually need their skills.
Many teams find this reduces noise for subject matter experts. They can concentrate on strategic work instead of handling every minor issue.
Challenges with Red button on-call model
You’ll probably need clear criteria for what counts as a red button incident. Without a solid definition, people might escalate routine problems too quickly or miss serious ones.
The subject matter expert usually needs to stay sharp between incidents. Long quiet periods can make it harder to respond quickly when a critical incident finally triggers.
Spike automatically reads incident severity from the payload. You can use Alert Rules to route SEV1 incidents to an escalation policy that points directly to your SME rotation. This means the right person gets paged without anyone having to make that call manually.
Run any on-call model with Spike
Spike makes it easy to set up these on-call models. The platform is flexible enough to handle multiple rotations, backup layers, and custom escalation rules.
You can create a shadow model with primary and backup responders. You can route VIP customers to a dedicated rotation. You can even combine follow-the-sun coverage with a red button layer for critical incidents. Spike also lets you sync your on-call schedule directly to your calendar so everyone always knows when their shift starts.
It gives you the freedom to experiment with different models until you find what works best for your team.
Get started with Spike and see how simple it is to build any on-call setup.
FAQs
How do you decide which model fits your team?
Start by identifying your biggest pain point. If sleep interruptions are the problem, follow-the-sun might help. If knowledge transfer is the issue, shadow on-call usually works well. Most teams find it helpful to try a model for a few weeks before deciding if it sticks.
How do we transition from a standard rotation to one of these models?
It usually works best to run a pilot first. Pick one team or service and try the new model for a few weeks. Gather feedback regularly. If it works well, you can gradually expand it. This approach lets you learn and adjust without disrupting your entire on-call setup.