DEV Community

Hive80-lab
Hive80-lab

Posted on

Nothing corrodes a rotation faster than the 2AM page that pays nothing

Nothing corrodes a rotation faster than the 2AM page that pays nothing. The engineer answers, resolves, logs it, and comes back the next morning to an inbox that never noticed they were awake from 2 to 3:40.

One unpaid night is solidarity. A quarter of them is a rotation that quietly stops answering — and then your on-call schedule is a document, not a system.

An on-call compensation policy is not a luxury for companies with HR departments. It is one page that says what being on call is worth, so nobody has to negotiate it at 2AM while an incident is burning. Write it before the first page, the same way you write the escalation policy before the first escalation.

First, decide what "on call" means for you

Before pay comes the restriction test: is on-call time constrained (you must stay reachable, sober, near your laptop) or free (you can hand the phone to a teammate and go hiking)?

That distinction decides whether the time is stipend-covered or legally work time in many jurisdictions — and it is the difference between "we pay you to carry the phone" and "we pay you for the hours the phone takes." Non-exempt employees legally may be working while on call; salaried-exempt misclassification is a classic expensive mistake. The policy template carries a "check with your accountant or local labor authority before first payroll" line, and that line is the most important one in the document. This is not legal advice — it is an ops template.

Then define engagement in one sentence: an engagement is any interruption initiated by someone else because you were on call. Not "incidents worked." Interruptions. The false positive at 11PM is an engagement; the "can you glance at the dashboard" Slack ping is an engagement.

Pick the pay model — then write down the exact arithmetic

Model A: stipend per shift. A flat amount per week or weekend on call, regardless of pages. Simple, budgetable, fair when page volume is low. Failure mode: a rotation that melts under a real incident season still pays the same — which is why the stipend needs engagement rules underneath it.

Model B: engaged time, hourly. Carry time is unpaid or stipend-covered; time actually spent responding is paid hourly (often 1× or 1.5× the effective rate) with a minimum increment. Fairest under low volume, most common for small teams. The arithmetic must be exact: "each engagement is paid a minimum of 30 minutes, rounded up to the next 15" — because a four-minute fix at 3AM took twenty minutes of human cost to even see.

Model C: hybrid. A small weekly stipend — the price of carrying the phone — plus engaged-time hourly on top. This is where most mature small-team rotations converge.

Whatever you pick, write the formula in the policy so a single line can be pointed at during any payroll dispute:

pay = stipend + (engaged minutes × rate, min 30 per engagement)
Enter fullscreen mode Exit fullscreen mode

And one honesty clause that earns its keep: there is no cap on incident pay. A cap converts every bad incident into a personal loss and quietly teaches people to stop engaging. Bad weeks are the company's problem, not the engineer's.

Count middle-of-the-night time like it is real, because it is

  • The engagement clock starts at the page, not at the login. The person who hears the pager at 2:07 and opens the dashboard at 2:11 worked from 2:07.
  • Interrupted sleep counts. A 1:40AM page resolved by 2:05 that leaves the person too wired to sleep until 3:30 is, practically, a 2:00–3:30 engagement. A simple rule handles it: engagements between 10PM and 6AM carry a minimum of 60 paid minutes, not 30. The number matters less than the principle: the cost of a night page is bigger than the duration of the fix.
  • False positives are still engagements. If monitoring wakes someone for nothing, that is a monitoring problem — and it is still paid time. A policy that pays false positives is the fastest known way to get the noisy alerts actually deleted.

Fairness in a thin rotation

Small teams rotate thin — a three-person rotation means every third week is constrained. Compensate for thinness deliberately:

  • The stipend exists even in zero-page weeks. The person who carried the phone all week and got lucky still did not get to plan an evening. Paying zero for a quiet week is how you teach people to resent the rotation.
  • Comp time for heavy weeks. More than N engagements (five is a common first guess) is a data point: either the product has a real problem or the rotation is too thin. Offer a half-day of comp time and trigger a look at the incident trend behind the number.
  • Swaps are allowed and paid. Whoever carries the pager gets the pay, regardless of whose name was on the schedule. Pay-follows-schedule rules create silent disputes over shifts swapped in good faith.

The one-page template

  • Header: who is covered (roles, not names — the policy survives team changes), effective date, review date. Review it quarterly, at the same cadence as the rotation.
  • What on-call means here: the restriction test result, the response SLA (acknowledge within X, engage within Y), and the devices/availability expected — laptop reachable, internet, phone charged.
  • What it pays: the model, the exact formula, the minimum increment, the night multiplier if any, and the cap-free honesty clause.
  • Exclusions and disputes: what does not count (a maintenance window the person chose to watch voluntarily; their own week swapped with a willing colleague — swaps keep the original pay split unless you say otherwise), and the dispute path: raised in the handoff, resolved by the ops lead within one payroll cycle.

Records: the boring half that makes it defensible

Log every engagement, same day. Timestamp, page source, duration, outcome. Two minutes per engagement. Without the log, payroll is memory, memory is dispute, and dispute is resentment. The log doubles as rotation-health data — it is where you will see that Tuesday pages tripled after that deploy pipeline change.

Pay from the log, not from memory. The payroll cycle pulls the engagement log, applies the formula, pays. Exceptions require a written note. And keep the records with the pay records: on-call pay is wages, and its records belong with payroll retention, not buried in a chat thread.

The policy is a living control

Every severe incident ends with a compensation check: when the postmortem is written, one line item asks whether anyone's on-call week absorbed an unusual load — and whether the policy paid it the way the policy promises. That loop is how the policy earns the trust that makes people willing to carry the phone.

Retire the policy the day it stops being true. Team grows, product gets a real on-call burden, the law where your people live changes — update the one page. A compensation policy untouched for a year is not a policy; it is a fossil the team works around.

The traps

  • Negotiating at 2AM. The whole point of the policy is that the rate was agreed by daylight.
  • The cap. Caps convert bad incident seasons into personal losses.
  • Pay-follows-schedule swaps. Pay the person holding the pager.
  • Memory-based payroll. Same-day log or it did not happen.
  • Copy-pasting a big-company policy. Rules written for 24/7 NOC staff with HR departments do not fit a five-person rotation — and the legal treatment of constrained time varies by country and state.

The full template — the restriction test, the three pay models with exact arithmetic, the night-page rules, the fairness rules for thin rotations, and the one-page policy you can adopt this week — is on the HIVE80lab ops notes.

If you're building out incident response for a small team: The First 30 Minutes is a free quick-start, the Ops Starter Kit ($14) covers the whole incident rail, and Vol. 2 ($27) adds communications and advanced response. Need it done for you? The Small-Team Ops Audit ($149) returns prioritized findings in five days.

Top comments (0)