Operations | Monitoring | ITSM | DevOps | Cloud

Over the past couple of weeks, as snowstorms and extreme cold swept across much of the Northeast, something interesting started happening on our end at OnPage. Our phones lit up. Not from healthcare teams or IT operations/tech teams, which is where many people expect us to be used, but from HVAC companies, contractors, and property management firms scrambling to prepare for what they knew was coming.

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.

For engineering organizations running on PagerDuty, on-call schedules are sacred. When P0 incidents happen, you need your best engineers focused and ready, not getting scheduled to conduct an interview they’ll have to decline. For years, recruiting teams have been playing a manual game of Tetris, cross-referencing on-call rotations against interviewer availability every single time they book a technical screen or panel.

ITIL 5 launched in January 2026, and for the first time in the framework's 40-year history, AI governance is front and center. If you're running incident management, on-call rotations, or building operational tooling, this matters: the gap between AI adoption and AI governance is about to become a compliance and operational risk issue. I’m not usually a big ITIL fan, but this guidance has some genuinely useful framing and questions.

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.

In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already going wrong? One answer, used quietly but consistently by high-performing teams, is the checklist.