On-call and release-night work: fair rules for compensatory time and pay

It is two in the morning and the payments service is failing. The on-call engineer wakes up, fixes a bad config, and goes back to bed at four. At ten she is in standup, tired. Nobody mentions the night. Two weeks later a release runs through Saturday, and three engineers ask the same question in the team chat: do we get time off for this?

Without a written rule, every on-call night and release weekend becomes a negotiation. This post sets out how to design fair rules for on-call duty, release-night work and compensation, using time off, pay or both.

Teams often lump all after-hours work together. The cost to the person differs, so the rules should too.

• Being on call: available to respond, usually from home, with no certainty of being called.
• Being called out: actually working during an incident, often at night.
• Planned release work: scheduled night or weekend deployments with a known start and end.

A person who is on call but never called still gave up their evening. A person who worked four hours at night needs rest the next day. A release weekend is a planned cost that the plan itself should limit. Describe each in your policy.

There are two common models. In the first, the company pays a standby allowance for being on call and adds time off or pay for actual work. In the second, it gives compensatory time off only. Some companies add rest rules, such as a late start after a night call-out. The right mix depends on your budget, your team size and how often incidents happen. Pick one and apply it to all engineers in the same role.

The company decides the amount of standby pay or the length of time off. Look at how often incidents occur, how disruptive they are and what similar companies in your market offer, then set a rule you can afford to keep.

1. 1

   Count who can be on call

   List the engineers who know the systems well enough to respond. A rota of two people is too thin; add people through cross-training.

2. 2

   Set the rotation length

   Choose a week or a few days per turn. Avoid back-to-back turns, and give swaps a clear process.

3. 3

   Name a second line

   Define who the on-call person calls if stuck, such as a lead or senior engineer. Tell them that escalation is expected.

4. 4

   Define what counts as an incident

   Agree severity levels and which ones justify waking someone. Minor issues wait until morning.

5. 5

   Record every call-out

   Log the date, start and end time, the system and what was done. This is the evidence for compensation and for fixing the causes.

6. 6

   Review monthly

   Look at the log, find the noisiest alerts and fix or remove them. The best on-call policy reduces the calls.

Release-night work should be planned, announced and rare. Give notice, name volunteers where possible, and limit the length of the window. Ask whether a daytime release with a feature flag would do the same job. If a night release is needed, agree the compensation before the work, not after.

Plan rest as well. A person who has worked late should not be expected in a morning review. Write down the rule, such as a later start the next day, so that managers do not decide it case by case.

Who is on the rota and how turns rotate.
What counts as an incident and the severity levels.
Response expectation, such as acknowledging within a stated time.
Second line and escalation route.
How call-out time is recorded.
Compensation: standby allowance, pay, time off or a mix, set by the company.
Rest rule after a night call-out.
Release window rules and notice period.
Swap and exception process.
Review date and policy owner.

The call-out log works only if people fill it in. Make it a two-minute task in a shared sheet or a tagged chat message. Review it with the team lead each month, and thank people for entries. If the log shows a person carrying far more calls than others, change the rota before they ask. Fairness is easier to keep than to rebuild.

Talk to the team before you publish the rule. Ask what has felt unfair so far: a call that came every night in one week, a swap that was refused, a release weekend nobody thanked. Those stories show where the rule needs to be firm. Then explain the rule in a team call, show the log format and take questions.

Managers need guidance too. Tell them how to approve compensatory time, what to do when a sprint is tight and how to respond when someone does not take the rest they are owed. A rule that managers quietly work around will not last.

Compensation is fair, but it does not fix tired engineers. Track repeated alerts, fix their causes, write runbooks and improve monitoring. A good rota should get quieter over time. If it does not, bring it to the product and engineering leads as a staffing and quality problem.

The same thinking applies to attendance and leave rules. See the attendance, shift and leave process page for how these are recorded. Teams building hiring plans around coverage can also read bench time and project gaps, which looks at the opposite problem. For how product companies handle these questions, see SaaS and product companies.