For the vast majority of organizations, it’s necessary to have some form of round the clock cover to support the business. Whilst it’s most commonly a concern for engineering, it’s increasingly common to have folks from various disciplines available out-of-hours.
Irrespective of role, compensating people fairly is an important factor of running a healthy and effective on-call system.
Let us calculate this for you!
If you're currently compensating folks for on-call, but cranking through spreadsheets manually, we can help! With incident.io On-call, you can configure your pay configurations and have us calculate everything on your behalf.
See more and try it for free here.
As with most things, there's no one-size-fits-all approach to on-call compensation. Here's a few of the common ones:
Many organizations don’t pay anything for on-call. The folks taking part in an on-call rotation are doing so out of the goodness of their heart, or because they’ve been asked (or forced 😬) to do so.
This approach is particularly prevalent in smaller companies where incidents aren’t especially severe, or the impact of downtime isn’t considered a significant concern. It’s also something we see in much larger organizations, where historical norms prevail and folks feel less empowered to ask for change.
If you’re considering this approach to compensation, it’s worth keeping an eye on how people are feeling over time. There’ll come a point where the impact on home life is meaningful enough that they expect to be compensated for the inconvenience. Left unchecked, it’s easy to end up with burnt-out or undervalued people who may look for opportunities elsewhere.
In this model on-call compensation is positioned as part of your base salary, and is commonly combined with expectations around how often you’ll be required to work out-of-hours. For example, you might have a base salary of $100k and an expectation that you’ll be on-call no more than one week in eight.
There’s a clear appeal to this approach as it’s a simple mechanic for paying folks without any complex monthly compensation calculations.
However, there are a few trade-offs to consider. Firstly, this model prevents folks from trading time without feeling indebted to each other. Since everyone is compensated equally, overrides are highly transactional; “I’ll take your week if you take mine”.
Additionally, people have a tendency to forget these kinds of agreements exist, and over time they may forget that they are being compensated at all. And since it doesn’t feel like they’re being paid ‘extra’ for that out-of-hours time, there’s a risk they’ll begrudge doing it.
With a pay per incident approach, on-callers are paid a fixed amount for every incident they attend. Typically it’ll apply to out-of-hours only, but every time you open your laptop to investigate an issue you were paged for, you get rewarded.
It’s clear to see where the positives are here: pay is correlated with the amount of active pain you feel, so the more you’re disrupted the more you’re compensated. A bad week of incidents is made a little less bad when you pocket a nice bump on your paycheck.
There are clear drawbacks to this method though, and in the worst case you can end up disincentivising work to make systems more reliable. If you’re going to be paid every time an alert fires, and you don’t mind being woken up, why take the time to fix things? This is clearly an extreme, and few people are likely to deliberately leave things in a poor state, but while the incentive structures are in place the risk is there.
Another failure mode is the fact that no incidents means no pay. It might sound reasonable on the surface, but when being on-call means you need to carry your laptop with you for a week, that’s an inconvenience you’re giving away for free.
This approach works by paying folks solely for the hours they spend on-call. Most commonly this is run as a weekly rotation, where on-callers are paid a fixed amount for the time they’re ‘holding the pager’.
In an ideal world, the compensation is worked out down to the minute taking overrides into account. In this world, when someone takes over part of your shift for you, they’re automatically compensated for their time which removes the pressure to trade shifts.
Ultimately this approach pays folks for the inconvenience on their home life, rather than their time directly. If you’re paid $300 for a full week of on-call, you’re essentially being compensated at a rate of $1.78 per hour. Not an amazing rate by any standards, but if it’s just covering you to carry a laptop around, it’s a pretty fair exchange.
As with the other approaches, paying by time also comes with some trade-offs. Firstly, it doesn’t work well when someone is on the receiving end of a bad week of on-call: that $300 is going to feel like a rough deal when you’ve been woken several nights in a row. For this reason, it’s helpful to pair it with an environment of proactive overrides: if someone’s been up in the night, offer to give them a 24-hour break.
The other failure mode is the fairness when there’s an imbalance of pager-load between teams. If I’m paid $300 per week and my team receives double the number of alerts of another, I’m likely to feel aggrieved. There’s no easy solution here, but one option is to consider different rates for ‘high’ and ‘low’ load teams.
There’s no such thing as a one-size-fits-all approach to on-call compensation. What you pay is heavily context-dependent and will vary based on your business, your incident load, the people who’ll be on-call, and a number of other factors.
However, if you keep things simple, pay people fairly, and are understanding of the impact out-of-hours work can have, you’ll be on the right path.
Everyone who is on-call should be compensated, whether they’re paged or not. Holding a pager is inconvenient. It means your non-work time isn’t completely yours, and you have to adjust your lifestyle accordingly. It’s not fair to ask anyone to do that for free.
Choosing compensation is (as always) a challenge. Choose a compensation amount that feels fair based on the criticality of your service and the typical frequency of incidents.
At incident.io, we pay ~$350 per week and expect to be paged a few times a week outside of working hours (and sometimes never!). We’ve written about our setup in more depth in On-call by default.
In larger organizations, a single flat per-hour rate for ‘on-call pay’ isn’t sophisticated enough. Different rotas will have different expectations, and it would feel unfair to compensate them all equally. We’d still recommend paying people by amount of time on-call, but with some additional tweaks to cater for a more diverse organization.
Splitting compensation by criticality and incident frequency
To reflect the differences in pager load, we suggest separate tiers of compensation in return for different expectations:
Since you’re paying folks for the inconvenience on the home life this approach feels justified. If you’re on a critical rotation and need your laptop with you at all times, it’s fair that you’re compensated higher than someone who can leave it at home whilst they head out for groceries.
Compensating folks who are pulled in opportunistically
It can also be useful to compensate those who aren’t on-call but are opportunistically pulled in to support with an issue. In this case, we’d recommend paying these people ‘per incident’, and tracking these escalations carefully. This reduces social barriers to escalating in this way as you knew the person you were paging would be compensated for their involvement.
If you’re interested in reading more about these kinds of complex setups, Monzo have written about their on-call setup here and here.