On-Call Compensation: Fair or Flawed?

It’s Saturday night. You’re out with friends, half-listening to a conversation when your phone buzzes. PagerDuty. CPU utilization spiked. You step away, pull out your laptop, and begin the familiar ritual: triage, troubleshoot, recover.

The system’s back. But your evening is shot.

This is the price of on-call. And for many SREs and DevOps engineers, the question isn’t whether they’ll be paged—it’s whether they’re paid fairly for it.

On-call compensation is a growing debate in reliability engineering. Some argue it’s essential hazard pay. Others say it’s part of the job. Still others argue the real issue isn’t money—it’s how we value time and boundaries.

Let’s break down both sides of the controversy.

The Case for Compensation

Let’s start with the basics: on-call is disruptive.

It fragments your personal time.
It prevents full rest and recovery.
It causes anticipatory anxiety.
It alters how you socialize, travel, and unwind.

This isn’t theoretical. Studies show that even the possibility of being interrupted at night elevates stress hormones and reduces sleep quality.

Fair compensation, then, is a recognition of that sacrifice. It signals that the organization values not just uptime, but the humans who maintain it.

Common compensation models include:

Flat-rate stipend for each shift/week.
Per-incident payment (e.g., $50/page).
Time-off in lieu (recovery days).
High base salaries to include on-call implicitly.

Each model has pros and cons—but the key idea is simple: if you’re asking someone to be available 24/7, you should acknowledge the cost.

What Compensation Achieves

Equity: Engineers who shoulder operational risk are rewarded.
Morale: Payment shows respect for work that often goes unnoticed.
Retention: Burned-out engineers leave. Compensated engineers are more likely to stay.
Transparency: Clear compensation avoids backroom resentment.

It also forces orgs to think carefully about coverage. If you pay for every on-call shift, you’re less likely to overburden a small team.

The Case Against Explicit Compensation

Yet not everyone agrees.

Some leaders argue that paying separately for on-call turns reliability into “extra work” rather than core responsibility. They say:

On-call is part of owning software.
Good systems shouldn’t page often.
You’re already paid well—this is baked in.

From this view, separate compensation might disincentivize investing in automation. If engineers are paid per alert, they may lack urgency to reduce them. Worse, it creates a transactional mindset: “I got paged—where’s my check?”

There’s also operational friction. Tracking on-call incidents, shift hours, and payouts creates administrative load. And at global companies, different labor laws and tax structures make consistent compensation hard.

Culture Clash: Devs vs. Ops

This debate also reflects a deeper divide: developers are often not on-call. SREs are. So when SREs ask for on-call pay, some devs wonder: “Why? I push just as much code.”

This can create tension. It highlights discrepancies in risk, recognition, and reward.

Organizations must tread carefully. If on-call is required, but only some are compensated, resentment brews. If everyone’s compensated, but only a few respond regularly, fairness erodes.

The Psychological Toll

Regardless of pay, on-call has a cost.

Missed birthdays.
Anxiety during vacations.
Poor sleep leading to errors at work.

These effects compound. They’re rarely visible. And they’re not fixed by a $100 stipend.

That’s why some argue that the real solution isn’t more pay—it’s less paging. Better SLOs. Smarter alerting. More automation.

In other words: don’t just compensate toil—eliminate it.

Real-World Practices

Companies vary wildly:

Google pays for on-call separately (in some roles), with generous time-off.
Startups often bake it into equity or salaries—but risk burnout.
Enterprise shops may have union-like compensation policies for ops teams, but not engineers.
Some orgs rotate on-call across devs and SREs to share the load and reduce impact.

There’s no one-size-fits-all. But the best companies do two things: they define expectations clearly, and they treat on-call as a design constraint, not an afterthought.

What Fair Looks Like

Compensation tied to burden: More alerts = more pay or more rest.
Recovery time guaranteed: You get a day off after a rough night.
Transparency in policy: Everyone knows how it works.
On-call optionality: Junior devs or new hires can opt-in, not be forced.
Mental health support: Pager fatigue is real. Don’t ignore it.

A Different Perspective: Recognizing vs. Rewarding

Some leaders propose a shift in framing.

Instead of seeing on-call pay as a reward, see it as recognition.

You’re not being paid because you fixed a bug. You’re being recognized for the availability you offered. The time you stayed close to Wi-Fi. The birthday you left early. The sleep you interrupted.

That kind of recognition is cultural. It’s about gratitude. It doesn’t always have to be money. But it does need to be intentional.

Final Thought

On-call is invisible until it isn’t.

When systems are stable, no one notices the engineers watching quietly in the background. When things go wrong, we expect them to jump in—immediately, calmly, effectively.

That’s a big ask.

So whether you compensate with cash, time, or culture, the principle should be the same: Respect the humans who hold the pager. Because the real question isn’t whether on-call is fair. It’s whether we’ve done enough to make it worth it.