{"id":4866,"date":"2026-01-29T13:43:27","date_gmt":"2026-01-29T08:13:27","guid":{"rendered":"https:\/\/blog.spike.sh\/?p=4866"},"modified":"2026-02-23T17:11:45","modified_gmt":"2026-02-23T11:41:45","slug":"who-should-be-oncall","status":"publish","type":"post","link":"https:\/\/blog.spike.sh\/who-should-be-oncall\/","title":{"rendered":"Who should be on-call"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

It is often more useful to look at whether your processes are ready. When incident responses<\/a> 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 usually works well until they go on holiday or move to a new role.<\/p>\n\n\n\n

On the other hand, when systems are documented and escalation paths<\/a> are clear, most people can be onboarded to on-call quite successfully.<\/strong> The knowledge becomes teachable. You might find that a junior engineer with access to documentation can resolve incidents faster than a senior engineer working from memory alone.<\/p>\n\n\n\n

So before asking who should be on-call, it is worth asking what needs to be in place first.<\/strong><\/p>\n\n\n\n

So, what needs to be in place?<\/h2>\n\n\n\n

It helps to have a few foundations in place before you add anyone to an on-call rotation. You might want to check for:<\/p>\n\n\n\n