On-Call Pay Policy Template: What to Include

A well-written on call pay policy removes ambiguity for engineers and makes payroll processing straightforward. Without one, you'll spend time fielding questions about edge cases — and you'll almost certainly pay people inconsistently across the team. This template covers every clause a solid policy needs.

1. Scope and eligibility

Define clearly who the policy applies to. Typical clauses include:

• Which roles are eligible for on call pay (e.g. Software Engineers, Platform Engineers, SREs)
• Whether the policy applies to permanent employees only, or also contractors
• The minimum schedule frequency required for eligibility (e.g. at least one on call shift per quarter)
• Whether management levels above a certain grade are excluded (senior managers covering informally usually are)

2. Availability stipend rates

This is the flat daily rate paid for being on the rota, regardless of incidents. Specify:

• Weekday rate — typically Monday–Friday excluding bank holidays. Example: £20 per day.
• Weekend rate — typically Saturday and Sunday. Example: £35 per day.
• Bank holiday rate — usually the highest tier. Example: £55 per day.
• Regional calendar — state which bank holiday calendar applies (England & Wales, Scotland, Northern Ireland, or per-engineer based on location).

3. Callout fee

The callout fee is triggered by an actual page — not just by being on the rota. Define:

• Fee amount — a fixed payment per incident the engineer responds to. Example: £40 per callout.
• What counts as a callout — typically any incident the engineer acknowledges in PagerDuty. Specify whether noise/auto-resolved alerts count.
• Callout cap — some policies cap the number of paid callouts per shift (e.g. max 3 per night) to limit liability on very busy periods. Others do not cap.
• Business hours exclusion — most policies do not pay a callout fee for incidents during normal working hours (9–5) since the engineer is already being paid their salary.

4. Minimum hours rule

If your policy pays an hourly rate for active work during incidents, you should define a minimum billing unit. Without this, a 10-minute wake-up at 3am generates almost no compensation despite significant disruption.

• Common minimum: 1 hour per callout, billed regardless of actual incident duration
• Some policies use a 30-minute minimum instead
• If a single incident runs longer than the minimum, bill actual hours rounded to the nearest 15 or 30 minutes

5. Hourly rate for active work

Not all policies include this — some use only the stipend and callout fee. If yours does include an hourly rate for incident work, specify:

• The rate itself (often the engineer's effective hourly rate based on salary, or a fixed rate)
• How hours are measured — typically from incident trigger to resolution in PagerDuty
• Whether hours during normal working hours are excluded
• How this interacts with the callout fee — additive, or does the callout fee cover the first hour?

6. Payment process

Even the best policy falls apart without a clear payment process. Include:

• Reporting period (e.g. calendar month, 4-week sprint)
• Who is responsible for generating the pay report
• Submission deadline to payroll (e.g. 3 working days before payroll cut-off)
• The format payroll expects (XLSX, CSV)
• Dispute resolution — how engineers raise queries about their pay figures

A note on currency

If your team spans multiple countries, state the currency for each rate explicitly and note whether rates are fixed in local currency or converted at a reference exchange rate. Leaving this ambiguous creates headaches every time exchange rates move significantly.

Reviewing the policy

On-call policies should be reviewed at least annually, and any time the on call load changes significantly. A team that rarely gets paged and one that handles dozens of incidents a month have very different on call burdens — your policy should reflect that.