Operations | Monitoring | ITSM | DevOps | Cloud

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.

On December 4th, 2025, we discovered an issue where the person shown as on-call on the dashboard didn’t match who was scheduled in the calendar. When we started investigating, we learnt that this only affected schedules with weekly rotations or weekly layers combined with custom timings.

Today, we are introducing some new on-call features: Add Gaps to on-call, Scheduled Layers, Handoff Days, and more. Flexibility in on-call schedules has been the single focus point in this release. These features give you much finer control over when people are on-call, how handoffs work, and what your schedule looks like around holidays and time off.

When your team shares one support number, someone has to decide who gets the calls when customers need help after hours. And if your team rotates on-call responsibilities weekly, which is common in IT (SRE, DevOps, ITOps, etc), clinical and field engineering teams, you’ve probably relied on manual call forwarding at some point. On paper, it seems straightforward: update the forwarding number each week to point to the person who’s on call. In practice? It often turns into a scramble.

OpsGenie is shutting down. And Atlassian recommends migrating to Jira Service Management (JSM). But if you’re not sure JSM is the right fit for your team’s on-call management needs, this review will help you decide. I signed up for JSM and put it through real-world testing. I created on-call schedules, rotations, and overrides. Then, I reviewed JSM’s on-call management across 4 key criteria. For each criterion, I shared what I liked and what I didn’t.