Who owns the pager?

Fri, 24 Jul 2026 00:00:00 +0000

I hate on-call.

I hate doing it, and I hate asking other people to do it, which is a slightly awkward position to hold when you’ve spent a decent chunk of your career around systems that other people expect to be awake all night.

Nice gentle start then…

The annoying bit is that on-call is also, in one form or another, necessary. We built a world where people expect software to work at three in the morning. Payments, bookings, shops, photos, logins, messages, the lot. Somewhere, somebody has promised a customer that the thing will still be there when everyone sensible has gone to bed.

So what do we do about it?

Mostly we suffer.

But it doesn’t have to be in silence.

It’s not the fixing I hate

I have done more than my fair share of on-call. I have been the point man for more businesses than I care to remember. The one who gets the call because a RAID controller has died, the disks need moving, and apparently the data centre becomes my natural habitat at two in the morning.

And, honestly, that is not the bit I hate.

Going to fix things is part and parcel of the industry we work in. If you build or run systems for long enough, one of them will eventually choose violence. Disks fail, networks sulk, certificates expire, queues wedge themselves in exciting new shapes, and some poor soul has to go and poke the thing until it stops screaming.

Fine.

Not fun, exactly, but fine.

What I hate is the bit around it. The out-of-hours expectation. The way life has to stop just in case an emergency happens. Or, if you are lucky, there is no emergency and you have simply wasted an evening stuck at home, not quite relaxed, not quite working, waiting for a phone to ruin the room.

That is the part we underprice.

We talk about the incident as if the cost starts when the alert fires. It doesn’t. The cost starts when someone stops being able to make normal plans because the business might need them. The cost is the half-watched film, the missed pint, the Sunday walk kept suspiciously close to signal, the family meal where your attention keeps drifting back to a rectangle on the table.

The phone may never ring, but the pager has still had the evening.

Follow the sun, if you have one

In a perfect world, on-call would be follow-the-sun.

Somebody in each time zone, working sane hours, handing responsibility around the globe like a relay baton. Nobody is being heroic. Nobody is being woken up. Nobody in Manchester is trying to decide whether an incident in Australia is worth climbing out of bed for.

Great.

If you work for a company big enough to have that shape, use it. Please use it. It’s one of the rare moments where being a large organisation can be turned into a kindness rather than a procurement process with shoes on.

Most of us don’t work in companies like that.

If you are UK-based and your users are on the other side of the planet, you have a problem. Not a moral failing, just a problem. You can sometimes soften it by splitting support into layers. A first-line partner in another time zone can catch the routine stuff, gather context, and reduce the number of times your second-line engineer gets dragged into the small hours. That won’t work for every business, and it will cost money, but at least it admits that geography exists.

The trouble is that a lot of companies skip the design work and jump straight to a rota.

A rota is not a strategy

You know the pattern.

On-call becomes part of the default responsibilities. A rota appears. It is enforced. Then some escalation rule gets bolted on that says if the engineer misses an alert, their line manager gets woken up too, and everyone pretends that is resilience rather than social pressure wearing a lanyard.

I have seen versions of this where the implied message is very clear: miss the wrong alert and somebody will remember it at review time.

That is not an on-call process. That is a threat with PagerDuty integration.

And yes, the threat works, in the same way holding a lighter under someone’s foot technically makes them move. It makes people jumpy. It makes them afraid to miss a notification. It makes them afraid to escalate too early, because now they are not just dealing with an incident, they are deciding whether to disturb a chain of increasingly senior, increasingly grumpy humans.

That fear has a cost.

It burns people out. It turns one week in the rota into a week of bad sleep before anything has even broken. It makes perfectly capable engineers decide the job is not worth the private-life tax. It scares off people who might have been the best hire you ever made, because they looked at the sentence about “occasional evenings and weekends” and quite reasonably decided they had better things to do than live under a corporate doorbell.

Then managers act surprised that hiring is hard.

Where is the reward? I hear some of you ask!

Exactly.

Opt-in has to mean opt-out

There is no clean solution to the on-call problem for small and medium-sized teams. Not really. If the business runs twenty-four hours and the team does not, somebody somewhere is carrying the awkward bit.

But there is compromise.

On-call should be a dialogue with the people carrying it, and with the wider team affected by it. Not a line slipped into a job description and rediscovered after the probation period. Not “we are a family here”, which usually means the family has mysteriously adopted a production database and given it your mobile number.

Make it opt-in where you can.

And if it is opt-in, it has to be opt-out as well. People’s lives change. Kids get ill. Relationships happen. Caring responsibilities appear. Health wobbles. Sometimes someone just needs a few months where their evenings are not owned by the possibility of a failing queue in a region they have never visited.

That should not require a confession booth and a tribunal.

If someone signs up, compensate them. Properly. A stipend in that month’s wages. Time off in lieu. Something tangible. Heck, send a basket of fruit or flowers if you must, though I would be mildly stunned if anyone chose that over cold hard cash. The point is not the exact shape of the benefit, it is the acknowledgement that availability is work.

Being interruptible is work.

Waiting is work.

Carrying the possibility of a call is work.

The business gets value from that, so the business should pay for it.

Plan it like it matters

The other deeply radical idea is planning.

I know, contain yourselves.

Plan the rota months in advance. Treat it like holidays. Leave room. Have a way for people to swap without turning it into a favour economy where the same dependable person keeps eating the awkward weekends because everyone knows they will say yes.

And never, if you can possibly avoid it, have one person on-call.

One person is a failure mode wearing shoes. Aim for three. Primary, secondary, and a backup who is genuinely available, not just a name in a spreadsheet that everyone hopes never gets tested. Because Bob will eventually have to rush to A&E at three on a Saturday afternoon after Little Timmy finds an imaginative way to make gravity his enemy, and if Bob is the whole plan then the plan is not a plan.

Capacity is not waste. Capacity is the thing that stops human life being treated as an edge case.

This is where automation helps too. There are plenty of tools now for on-call management, incident response, alert routing, observability, status updates, handovers, all the shiny bits. Use them. Use the boring bits as well. Silence alerts that do not matter. Add runbooks. Make the dashboards tell the truth. Make the alarm carry enough context that the person waking up can actually act instead of starting every incident with a scavenger hunt.

And once someone has been woken up, give them the authority to make the next wake-up less likely.

That bit matters.

If all you do is drag people out of bed, point them at the smoking hole, and then send them back to normal work with no time to fix the cause, you have not built on-call. You have built a recurring invoice for human misery. The pager should feed the improvement loop. Every escalation is evidence. Every call-out is the system telling you where it hurt, and if the same person responds to the same incident three times in a month, that person has a story the company needs to hear.

Listen hard.

Because that story might save the employee. It might also save the company from the reputational damage that comes when customers keep hitting the same broken bit and eventually realise nobody is learning from it.

The result of every on-call event, no matter how small, should be a lesson of some kind. Something that benefits the customer, the employees, and the company as a whole. It doesn’t always need a ceremony, a meeting, and a twelve-page incident report with seven action items nobody will ever read again. Sometimes the lesson is a runbook tweak, a threshold change, a clearer dashboard, a better handover note, or deleting an alert that should never have existed in the first place.

Incidents should create space to reduce future incidents. If the same thing wakes someone up twice, the second wake-up should come with some very sharp questions attached.

Preferably asked in daylight, with coffee.

The most important part is not the tool. It is not the rota template. It is not the escalation policy, the observability platform, or the impressive-looking incident command channel with seventeen bots in it.

It is trust.

As an employer, you have to communicate clearly with the people doing on-call. What is expected. What is paid. What counts as urgent. What happens if they miss a call because they are human, asleep, in a tunnel, dealing with a sick child, or simply failed by the same mobile network the rest of us use to watch videos of people falling off ladders.

And you have to mean it when you say they won’t be punished for opting out.

That is the bit that decides whether the process is healthy. Anyone can write “work life balance” in a handbook. The test is what happens when a good engineer says, “I cannot do this for a while.” If the company throws a hissy fit, the handbook was decorative.

On-call is not a favour engineers do for the business. It is not a loyalty test. It is not a little leadership trap where the most responsible people get rewarded with more invisible labour because they are the safest pair of hands.

It is a business requirement that lands on a human being.

So who owns the pager?

The company does.

The human just carries it for a while. Treat that properly, and on-call can be an awkward compromise that keeps the service alive without grinding the people down. Forget it, and all you have done is rent someone’s private life by the hour while pretending it is engineering.