Operations | Monitoring | ITSM | DevOps | Cloud

On-call duty is a high-stakes reality in modern IT and digital ops teams. While essential for ensuring system reliability, the chronic stress it creates doesn’t have to be a given. On-call burnout is a serious threat to your team’s well-being and your organization’s performance, but it isn’t inevitable. It’s a systemic problem, not a personal failing.

Many teams invest time building an on-call rotation, but inbound calls often ignore that structure completely. A support number forwards to a single phone. One engineer ends up taking every call. Sometimes the call goes unanswered and the voicemail lands in a shared mailbox that nobody checks until the next morning. Even worse, the team might have several engineers on duty, but the phone system has no awareness of who is actually responsible at that moment.

Our On-call product has a lot of great features: configuring escalation paths, viewing rotas and schedules, requesting cover, etc. However, when framing its reliability, we reduce it down to two critical pieces of functionality: It’s not that we’re happy if only these parts are working, but they are the most important parts. In this post, I'll go into more detail on how we think about their reliability.

A simple round-robin rotation works well when you have a small team with a single service and predictable incident patterns. It breaks down quickly when you have engineers across three continents, multiple services with different criticality levels, a mix of senior and junior responders, and a team that expects fair, sustainable coverage across weekends, holidays, and different time zones.

Your on-call rotation lives in a scheduling tool or a spreadsheet. Your engineers' actual work schedules live in Google Calendar. When these two systems do not talk to each other, engineers are constantly context-switching to figure out who is on-call and when. They miss shift reminders. They schedule personal appointments during on-call windows. And handovers get messy because nobody has a single place to see the full picture.

Schedules are a core part of any on-call system. In ours, they define who to page and when. But people use them in lots of other ways too: checking their next shift, asking for cover while at the gym, keeping a Slack user group up to date, or updating a Linear triage responsibility. For many of our customers, they’re one of the main ways they interact with our product, and as they’re such a foundational part of On-call, it’s very important they work well.

Most teams don’t go looking for “call routing software.” They’re trying to solve something more immediate: calls coming in after hours, no clear owner, and something important getting missed.