What are the common ways companies compensate engineers for carrying an on-call pager, and why do SRE teams often cap that compensation?
answer
- cash stipend or time off in lieu
- paying for restriction, not just incidents
- cap keeps the incentive aligned
- comp time automatic after night page
- "part of the job" prices it at zero
basics
~20 sTwo mainstream forms exist: cash — a per-shift stipend, sometimes plus payment for incident time — and time off in lieu. Google's SRE book describes capping either at a small proportion of salary, so that a noisy pager never becomes income anyone has a reason to protect.
solid answer
~50 sThe two normal models are a cash stipend per shift, sometimes topped up for time actually worked during incidents, and time off in lieu — comp time granted after the shift, especially after a night that was interrupted. Many teams combine them and let the engineer choose. The interesting part is the cap: Google's SRE book describes limiting on-call compensation to a modest proportion of overall salary, and the reasoning is incentive alignment. If a brutal rotation pays well enough to matter, some people will quietly prefer the pager to stay loud, and the team loses its appetite to fix the alerts. Capping keeps the reward for a quiet pager pointing the right way. Alongside pay, the norms that matter are automatic comp time after an overnight page and not expecting full project output from someone during their shift week. Standby pay is also regulated in some jurisdictions, so local law can set a floor.
go deeper
Be able to name the two models — a per-shift cash stipend and time off in lieu — and say that comp time after an overnight page should be automatic rather than something you negotiate for.
Explain the incentive logic of the cap: uncapped pay makes a noisy pager valuable to the people best placed to quieten it, which undermines alert cleanup.
Argue the operational norms as policy — reduced delivery expectations during a shift week and a genuine right to hand off — and connect the visible cost of compensation to funding reliability work.
Own the whole package: design compensation, staffing and delivery expectations together, check it against local employment law on standby and rest, and be able to defend why the cap exists to the people it limits.
## Why compensation is an SRE topic at all On-call compensation looks like an HR question and gets asked in engineering interviews anyway, because it is one of the clearest places where an incentive is deliberately designed. The team's goal is a quiet pager. Any compensation scheme that makes a loud pager attractive works against that goal, and the fix is structural rather than moral. ## The mainstream models **Cash.** Usually a flat stipend per shift — often differentiated between weekday, weekend and holiday coverage — sometimes with additional payment for hours actually worked during incidents. It is simple, visible, and it recognises that being reachable is itself a restriction on your life even on a quiet night. **Time off in lieu.** Compensatory time off proportional to the shift carried, plus, importantly, immediate comp time after a disrupted night: a late start or a day off after being woken. Some teams grant a fixed amount per rotation week regardless of how eventful it was. **Both, with a choice.** Common in larger organisations, since engineers value the two very differently. The restriction, not just the interruptions, is what is being paid for. Being on-call constrains where you can be, what you can drink, and whether you can be unreachable, even during a shift where nothing fires. Schemes that only pay for incidents worked miss this, and tend to be resented. ## The cap and its logic Google's SRE book describes capping on-call compensation — whether cash or time off — at some proportion of overall salary. The reasoning is worth understanding because it is counter-intuitive: the cap is not primarily cost control, it is incentive design. If on-call pay is uncapped and scales with how eventful the rotation is, a genuinely bad pager becomes a meaningful source of income. Some people will then, entirely rationally, stop pushing to remove alerts, and may prefer the rotations that pay most. That directly opposes the thing the team is trying to achieve. A cap breaks the link: the pager is compensated fairly, but nobody's finances depend on it staying noisy. There is a secondary benefit. Because the compensation is bounded and predictable, its total cost is visible to management as a line item, which supports the argument that reducing pager load saves real money. ## The norms that matter as much as the money Compensation is the easy half. The operational norms carry at least as much weight: - **Automatic comp time after an overnight page.** Not "ask your manager" — automatic. If an engineer has to negotiate for sleep, most will skip it and work tired. - **Reduced delivery expectations during a shift week.** The on-call engineer's output that week is on-call plus cleanup. Rosters that assume full project velocity during on-call are how burnout is manufactured while looking fully staffed. - **A real right to hand off.** Illness, emergencies and exhaustion need an override path that does not require heroics. This is scheduling machinery, but the *norm* is that using it is unremarkable. - **Legal floors.** Standby and on-call arrangements are regulated in some jurisdictions, with requirements around standby pay, rest periods and working-time limits. Any real scheme must be checked against local employment law rather than designed purely from first principles. ## What a weak answer sounds like "It's part of the job" is the classic. It is not wrong that on-call is part of an operations role; it is wrong as a compensation policy, because it prices at zero something with a real cost, and things priced at zero get over-consumed. Teams that treat on-call as unpaid duty accumulate the cost anyway — in attrition, in people declining to join rotations, and in nobody having time or motivation to clean up the alerts. The other weak answer is pure incident-based hourly pay, which pays nothing for a quiet but restricted weekend and pays best when the service is worst. ## In an interview You will rarely be asked to design a scheme. You are far more likely to be asked what a healthy arrangement looks like, or to notice the incentive problem when a poor one is described. Naming both models, explaining the cap's incentive logic, and mentioning automatic comp time after an overnight page covers essentially everything the question is looking for.
- Why is paying purely for hours worked during incidents considered a poor scheme?It pays nothing for a quiet but restricted weekend, when the engineer still could not travel, drink or be unreachable — the restriction is most of the burden. It also pays best precisely when the service is worst, rewarding the state the team should be eliminating. A per-shift stipend prices the restriction, with incident hours as a top-up if needed.
- How does a compensation cap connect to alert cleanup actually happening?It keeps everyone's interest pointing the same way. Under an uncapped scheme, a noisy rotation is worth real money, so the people best placed to remove alerts have a quiet reason not to. With a capped stipend, nobody loses income when the pager goes quiet, and the only remaining incentive is the obvious one: fewer interruptions.
saying these in an interview costs you the question
- Saying on-call is just part of the job, uncompensated
- Paying only for incident hours, ignoring the restriction
- Making comp time after a night page a manager's favour
- Assuming uncapped on-call pay has no downside
- Expecting full project delivery during a shift week