Operations | Monitoring | ITSM | DevOps | Cloud

When you move past daily rotations but find anything longer than a week feels too stretched out, you often end up choosing between weekly and split-week rotations. Weekly rotations give you a full seven days before handing off. Split-week rotations break that time into smaller chunks like 2-day, 3-day, or 4-day shifts. Each approach creates a different rhythm for your team. This guide compares both patterns across three key criteria.

Teams that find a weekly rotation too long and a daily rotation too short often end up choosing between 2-day and 4-day rotations. This guide compares both these rotations across three key criteria. For each criterion, we have discussed how it works for 2-day and 4-day rotations and recommended what to choose when. To make it easy, we also included a comparison table for a quick overview. This gives you all the information you need at a glance. Let’s dive in! Table of contents.

Choosing an on-call rotation is about finding a rhythm that balances your team’s well-being and your system’s reliability. The right on-call rotation helps prevent burnout and makes on-call duties sustainable over the long run. This guide walks you through different on-call rotation patterns, from daily rotation to after-hours rotations. We’ll look at why you might choose a particular rotation and the challenges that often come with it.

There is often a temptation to stretch on-call shifts to a month or longer, especially when incident volume is low. The logic seems sound. If the phone rarely rings, it feels unnecessary to hand off on-call duties every week. But looking strictly at incident volume often misses the human side of the equation. Being on-call isn’t just about answering pages. It is also a state of mind. Even when it is quiet, simply being on-call could create fatigue of its own.

An on-call responder is the first line of defence when something breaks. They assess the situation and take appropriate action. This guide walks you through what that actually looks like. You’ll see how on-call responders think through an incident and figure out what needs to be done.

There usually isn’t a hard and fast rule about who should be on-call. Teams often look for criteria like seniority, experience, or expertise. While those factors certainly help, they might matter less than you think. It is often more useful to look at whether your processes are ready. When incident responses rely on memory and intuition rather than documentation, even experienced engineers can struggle. They might handle things through internal knowledge that isn’t available to everyone else.

This guide covers some best practices that can make on-call handoffs a bit smoother. You’ll find suggestions on when to schedule handoffs, what to discuss during handoffs, and how to keep everyone updated on who’s currently on-call. Table of contents.

Going on-call for the first time can feel a bit overwhelming, but a little prep work makes it smooth and stress-free. This guide covers five things to set up before you start your first on-call shift. They help you stay on top of your schedule, get on-call notifications, and have a backup in place. By the end, you’ll be ready to handle your first on-call shift with confidence.

Setting up on-call is simpler than it seems. It comes down to a few clear decisions about your team and what your service actually needs. This guide walks you through those decisions. You’ll learn who to add in your rotation, how long shifts should last, when to hand off, and what coverage makes sense for your service. By the end, you’ll know exactly how to set up your first schedule and move from ad-hoc firefighting to organized incident response.

In the past, our yearly recaps were mostly about numbers. What we shipped, how much Spike grew, and a long list of stats. See past recaps: 2023, 2024. But 2025 felt different to me. It had many moments that shaped how Spike as a product and the company looks today. Some of them were exciting. Some were uncomfortable, and all of them changed how I think about building Spike. We’re still bootstrapped and operating lean, with a team of fewer than ten people.