# On-call compensation models: stipend vs hourly vs flat fee vs per-page

*September 8, 2026*

> TL;DR: Choosing an on-call compensation model means balancing budget predictability against engineer burnout. incident.io's survey of 200+ organizations puts the average weekly on-call rate at $540, a weekday average, with individual flat-rate payments spanning $5 to $1,000 per month. For small teams, flat weekly stipends keep costs simple and predictable, but they can mask alert fatigue. For larger teams, a dual-component model (standby pay plus active incident premiums) ties pay more closely to actual toil. Manual tracking is an administrative tax that introduces payroll errors and compliance risk, which is why teams use incident.io Pro at $45 per user per month with on-call ($25 base plus $20 on-call add-on) to automate on-call scheduling and escalation paths in Slack, and calculate on-call pay from that same schedule data.

Many Series A startups design their on-call compensation on a napkin. Early policies often start as a flat weekly stipend and a spreadsheet, and hold up fine until alert volume spikes and the arrangement stops feeling fair. By then the damage shows up in retention: a devops.com analysis citing the Catchpoint SRE Report 2025 found that nearly [70% of SREs](https://devops.com/the-end-of-alert-fatigue-how-ai-powered-observability-is-transforming-sre-teams-in-2026/) report that on-call stress has contributed to burnout and attrition on their teams.

This guide covers the four on-call pay structures used by high-growth startups: weekly stipends, hourly pay for active time, flat per-rotation fees, and per-page rates. It also covers the dual-component hybrid most scaling teams land on, with dollar benchmarks and recommendations for teams at different scales.

## Weighing the key tradeoffs of major on-call pay models

Every on-call pay structure trades the same two forces against each other: finance wants a predictable monthly number, and engineers want pay that tracks how bad the week actually was. No model wins on both axes, so the right choice depends on your team size, alert volume, and how much administrative work you can absorb.

One requirement stays constant across every model: you need trustworthy data on who was on-call and when they were actively working. When we [benchmarked on-call practices](https://incident.io/content/uncovering-the-mysteries-of-on-call), issues with tracking and reconciliation kept surfacing where schedules and payroll data lived in different systems.

### Using weekly stipends for predictable budgets

You pay a fixed weekly amount for carrying the pager, whether zero alerts fire or 15. Finance loves this model because the cost line never moves, and engineers accept it while systems stay stable and pages stay rare.

### Combining standby pay with active premiums

The dual-component model splits compensation into standby pay for being available (passive time) and an active incident premium for hours spent resolving pages. Many scaling teams land here because it pays for sacrifice and toil separately, so each side can be tuned independently.

### Structuring predictable flat-rate on-call pay

Flat per-rotation fees pay one fixed amount for a full rotation, such as $500 for a week-long shift. Payroll processes it like a bonus line item, and nobody tracks hours at all.

### Comparing how each model shapes resolution behavior

Pay structures shape behavior. Pure hourly pay can quietly reward slow resolution because every extra troubleshooting minute is billable, while flat models pay the same whether the fix takes 20 minutes or three hours, so nothing in the payout rewards a slower fix. That distinction matters for Mean Time To Resolution (MTTR): you want the money pointed at resolving incidents, not prolonging them. Escalation paths with [configurable timeouts](https://docs.incident.io/on-call/escalation-paths) reinforce that pressure by routing stalled pages to the next responder.

## Evaluating weekly stipends: pros, cons, and team impact

The weekly stipend is where most startups land first, because it takes one spreadsheet row to run.

### Budgeting for weekly on-call stipends

Our survey of 200+ organizations puts the [average weekly on-call rate](https://incident.io/content/uncovering-the-mysteries-of-on-call) at $540, a weekday average, with individual flat-rate payments ranging from $5 to $1,000 per month. Weekend coverage costs more, not less: respondents were generally paid about twice as much for weekend on-call as for an equivalent weekday shift, so budget the weekend slot at a premium rather than a discount.

The math for finance is simple:

1. **Count rotation slots:** three weekly rotations (primary, secondary, weekend).
2. **Set the rate:** $540 per week per slot, using the survey average. Budget weekend slots at a premium (survey respondents were generally paid about twice the weekday rate), but use your own data rather than doubling the $540 benchmark directly.
3. **Multiply out:** (3 slots x $540) x 52 weeks = $84,240 per year as a floor, before any weekend premium.

### Recognizing when stipends suit your team

Stipends work best when system stability is high and alerts are rare. You are paying for the constraint itself: staying near a laptop, skipping alcohol, keeping the phone loud overnight. When pages stay at a handful per week, most engineers consider that a fair exchange.

### Understanding how stipends contribute to burnout

A $540 weekly stipend sounds reasonable until you do the math on a bad week. If the engineer spends 15 hours actively resolving incidents, the stipend values that late-night toil at $36 per hour, well below a senior engineer's loaded cost and before you account for lost sleep. The failure mode is common: alert volume climbs as you ship more surface area, the stipend stays flat, and engineers begin looking for roles with better on-call terms.

Stipends only survive contact with growth if you pair them with strict alert hygiene and an escape hatch for brutal weeks, such as comp time or an active incident premium. Watch per-rotation page counts in your [Insights dashboard](https://docs.incident.io/insights/core-dashboards) so a creeping alert load triggers a policy change before a resignation does.

## Understanding hourly pay for active time: how it works and tradeoffs

The active-time model pays for hours worked rather than for availability. Here is what it costs to run and where it tends to break down.

### Budgeting for hourly on-call shifts

For non-exempt engineers paid overtime for on-call work, long-standing [SHRM guidance](https://www.shrm.org/topics-tools/news/benefits-compensation/call-pay-premiums-expenses-technical-employees) reports companies typically pay 1.5x the standard hourly rate. Exempt engineers are more commonly paid a flat weekly amount, though many teams set a flat hourly rate regardless of seniority. Budgeting requires a forecast, not a fixed number:

1. **Pull history:** export the last 90 days of incidents and estimate active response hours.
2. **Apply the rate:** multiply hours by your chosen hourly figure.
3. **Add buffer:** build in variance because incident volume arrives unevenly.

### Identifying ideal scenarios for active time pay

This model fits teams with volatile alert volumes, especially infrastructure groups whose incident load spikes unpredictably. Every minute of active incident toil gets compensated, so engineers feel respected even after a miserable week.

### Accounting for hidden costs of hourly models

Hourly models live or die on time tracking quality, and manual tracking is the weak link. When the "timesheet" is an engineer's memory of a late-night outage reconstructed from Slack scroll-back, your payroll input is guesswork. At a $150 loaded hourly cost, an hour of reconciliation per month runs $1,800 a year, before counting the follow-up conversations.

## Understanding flat per-rotation fees: simplicity and its cost

Flat per-rotation pay trades precision for simplicity. What follows is what teams typically budget for it, and where the model creates friction.

### Budgeting for flat-rate compensation

A flat fee pays one amount per completed rotation, typically in the range of several hundred dollars for a week-long slot. The annual math is a single line: for example, 52 weeks x $500 = $26,000 per year per rotation slot.

### Applying a fixed-fee approach

Simplicity is the whole pitch. There are no active hours to track, no disputes about when an incident started, and engineers know exactly what lands in their paycheck at month end.

### Avoiding hidden downsides of rotation fees

Flat fees create perceived inequity across rotations. If one engineer draws a silent week and the next gets paged eleven times, both receive identical pay for wildly different levels of toil. Engineers remember their worst week, not the annual average, and frustration builds if the same people keep drawing bad rotations.

## Understanding per-page pay: mechanics and hidden costs

Per-page pay attaches a dollar figure to each alert. It is the rarest of the four approaches our survey respondents described: among those who are paid for on-call, only 2% are paid per incident, against 71% on fixed pay for time spent on-call.

### Budgeting for per-page compensation

Per-page models pay a flat rate per alert. Build the budget from history: pull last quarter's P1 and P2 counts, multiply by the rate, and classify alerts by [priority level](https://docs.incident.io/alerts/priorities) so only genuinely urgent pages trigger payment.

### Identifying ideal use cases for per-page pay

Per-page pay creates a direct financial incentive to clean up noisy alerts and fix flaky monitors, because every page has a visible cost. It works best for low-volume, high-stakes systems where each page genuinely warrants immediate attention.

### Managing risk factors in per-page pay

We wrote about the core failure mode in our [guide to fair on-call compensation](https://incident.io/blog/fair-on-call-compensation): if you get paid every time an alert fires, the incentive to fix the root cause weakens. The opposite failure mode stings too, because no incidents means no pay, even though the engineer carried a laptop around all week for free.

Budget volatility is the other risk. A single service failure can cascade into pages across every dependent system, so cap your exposure with alert filtering and [rate limits on noisy sources](https://incident.io/changelog/shard-alert-source-rate-limits) before you attach dollars to pages.

## Choosing the right pay structure for 20 engineers

At 20 engineers, keep the model simple enough to explain in one Slack message. Our [on-call for startups](https://youtube.com/watch?v=pAaXiQkBRuQ) session covers this stage, and the core advice is: do not build a complex tracking system before you need one.

### Managing on-call costs for small teams

Time-in-lieu (comp time) is the most common non-monetary supplement at this stage, but the legal lines are sharp. The Fair Labor Standards Act (FLSA) does not let private-sector employers substitute time off for overtime pay owed to non-exempt staff. Compensatory time off is available only to [state and local government employers](https://webapps.dol.gov/elaws/whd/flsa/otcalc/doc7oi1.asp), at 1.5 hours per overtime hour worked. For exempt engineers, comp time is typically a policy choice rather than a legal requirement, which makes it a useful pressure valve after brutal weeks.

### Managing pay equity and simplicity

Fairness questions get loud when a founder and a new hire carry the same pager for different effective pay. Publish the policy, rotate everyone equally, and make the schedule visible where people already work. We sync rotations into Slack and [notify the channel when schedules change](https://docs.incident.io/on-call/slack-schedule-notifications), so nobody discovers they are on-call mid-incident. Our panel on [building a successful on-call team](https://youtube.com/watch?v=crcHkVfiwK4) covers the cultural side of this rollout.

### Applying best practice on-call pay models

The starting point we recommend for a small team: a flat weekly stipend benchmarked against the $540 average, adjusted down for a genuinely quiet pager, plus a written policy that brutal weeks earn comp time. You can [stand up the rotation itself](https://docs.incident.io/on-call/getting-started) in days, not weeks, which keeps setup costs low and gets the policy running before the next bad week.

## Choosing the right pay structure for 80 engineers

At 80 engineers, the decisions around compensation shift. Here is what changes and how to handle it.

### Balancing equity and streamlining payouts

At 80 engineers, flat stipends break down because alert volume stops being evenly distributed. Teams with heavier on-call loads may field far more pages than others, and paying every team the same stipend reads as unfair to the people carrying the heavier load. This is where a dual-component model stops being optional, and manual tracking starts costing real hours: at a $150 loaded hourly cost, two hours of monthly reconciliation is $3,600 a year.

This is the problem our compensation calculator solves. incident.io Pro runs $45 per user per month with on-call ($25 base plus $20 on-call add-on), and it tracks who held each shift, calculates payouts against your custom model, and exports clean CSVs for payroll. You can [generate an on-call pay report](https://docs.incident.io/on-call/pay-report) straight from schedule data instead of reconciling spreadsheets at month end.

> "I really love the slack integration, the automated summaries and the On Call pay reports feature." - [Verified user on G2](https://www.g2.com/products/incident-io/reviews/incident-io-review-10310467)

### Understanding why startups delay dual-component models

Many teams delay the dual-component transition long after it makes sense, often because their tooling makes hourly tracking painful to run. Where the on-call tool has no native compensation calculator, finance ends up stitching together exports and spreadsheets. That tooling gap is one reason teams [migrate their on-call to incident.io](https://youtube.com/watch?v=P7UZAnBTa9g) before redesigning pay, and our [PagerDuty migration tooling](https://docs.incident.io/getting-started/migrate-from-pagerduty) bulk imports schedules and escalation policies so the policy change stops being an infrastructure project.

## Comparing costs for your on-call rotation

The four models differ on cost, predictability, and administrative load. Here is how they compare.

### Managing on-call cost volatility

Stipends and flat fees give finance a fixed number, while hourly and per-page models float with incident volume. Tooling costs behave the same way: where on-call, incident response, and status pages are sold as separate add-ons, the invoice grows alongside usage.

Our pricing stays flat by contrast: incident.io Pro costs $45 per user per month with on-call ($25 base plus $20 on-call add-on), and the compensation calculator is included with on-call rather than sold as a separate module.

The comparison below draws on our survey data, plus published compensation guidance for technical staff:

| Pay model | Typical rate | Budget predictability | Admin overhead |
| --- | --- | --- | --- |
| Weekly stipend | $540 / week, weekday average | High | Low |
| Hourly (active time) | 1.5x base hourly (non-exempt) | Low | High (unless automated) |
| Flat per-rotation | ~$500 / week-long slot | High | Low |
| Per-page rate | Set per alert, varies by volume | Low | Medium |

### Evaluating perceived equity in on-call pay

Perceived fairness tracks how closely pay follows toil, which puts dual-component models ahead of per-page models, where quiet weeks pay nothing. Salary-percentage hourly models, where the hourly on-call rate is set as a percentage of each engineer's annual salary, create their own inequity because senior and junior engineers receive different pay for the same overnight page. Flat hourly rates sidestep this by paying everyone the same for the same work.

### Assessing maintenance needs per model

Manual hourly tracking carries the heaviest administrative load, and automation flips the ranking entirely. Setup effort matters as much as ongoing effort, and teams migrating to incident.io find the operational lift is small, with most getting operational in days rather than weeks.

### Matching pay models to team size

| Team size | Common starting model | Key advantage | Primary risk |
| --- | --- | --- | --- |
| Small teams (~1-20 engineers) | Fixed stipend + comp time | Simplicity | Can mask alert fatigue |
| Mid-size teams (~21-80 engineers) | Stipend + active time premium | More equitable | Manual tracking overhead |
| Larger teams (80+ engineers) | Dual-component (automated) | Scales fairly | Requires dedicated tooling |

The pattern: add structure only when the pain justifies it, and automate tracking the moment you introduce variable pay.

## Addressing key factors in on-call compensation

Beyond the pay model itself, several legal, operational, and structural considerations affect how you design and run an on-call compensation policy.

### Understanding on-call pay as taxable income

On-call compensation typically counts as [taxable wages for IRS purposes](https://www.irs.gov/publications/p15), subject to income tax withholding and FICA, and non-exempt staff generally must receive [1.5x their regular rate](https://www.dol.gov/agencies/whd/fact-sheets/23-flsa-overtime-pay) for active response time beyond 40 hours per week.

The legal line that matters most is the FLSA distinction between "[engaged to wait](https://www.dol.gov/agencies/whd/fact-sheets/22-flsa-hours-worked)" and "waiting to be engaged." An employee required to remain on the employer's premises is working while on call, while an employee free to stay home and be reachable generally is not. For exempt software engineers the FLSA generally does not require any additional on-call pay, but the legal floor is not the retention floor.

Courts weigh the whole picture rather than any single rule: response window, page frequency, and the engineer's personal freedom. The Department of Labor's own caveat is that "[additional constraints on the employee's freedom](https://www.dol.gov/agencies/whd/fact-sheets/22-flsa-hours-worked)" could require standby time to be compensated. A roughly 20-minute response requirement was held non-compensable in Bright v. Houston Northwest Medical Center, where the employee could still use standby time for personal activities (shopping, dining, movies) despite frequent call-outs, and compensable in Renfro v. City of Emporia, where call-out frequency, strict response restrictions, and callback disruption to personal time together rendered standby compensable. Your written policy should define response expectations explicitly, because it is the combination of a tight window and a busy rotation that moves standby toward paid work time.

A short compliance checklist:

* **Response windows and location freedom:** the tighter the window and the stricter the proximity rule, the more likely standby counts as paid work time.
* **Written agreements:** get the policy signed before the rotation starts, not after a dispute.
* **Payroll classification:** run stipends and premiums through payroll as taxable wages, never as expense reimbursements.

Run the final wording past your legal team before the policy goes out.

### Scheduling across regions and time zones

Once you hire across the US, Europe, and APAC, a single weekly rotation stops working. Follow-the-sun schedules hand the pager between regions so nobody carries overnight coverage permanently. European rules constrain this further: the EU Working Time Directive [mandates rest periods](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32003L0088) of 11 consecutive hours in every 24-hour period.

A 2018 Court of Justice ruling found that home standby carrying an 8-minute response obligation [counted as working time in full](https://curia.europa.eu/site/upload/docs/application/pdf/2018-02/cp180014en.pdf). The Court's 9 March 2021 rulings in [_Radiotelevizija Slovenija_](https://curia.europa.eu/juris/document/document.jsf?docid=238744&doclang=EN) (C‑344/19) and [_Stadt Offenbach am Main_](https://curia.europa.eu/juris/document/document.jsf?docid=238745&doclang=EN) (C‑580/19) later narrowed that, holding standby counts only when its constraints very significantly affect the worker's free time. Build handovers so they respect the rest window in each region, not just the coverage gap.

### Managing different pay structures per team

Different teams often face different on-call loads, and forcing one model across all teams creates friction. Run separate rotations with separate compensation logic per team, and [sync each rotation](https://docs.incident.io/on-call/sync-slack-groups) to its Slack user group so the right people always hold the pager for their services.

### Compensating for quiet on-call periods

Standby pay exists precisely for quiet weeks: the engineer gave up freedom (staying near a laptop, skipping drinks, keeping the phone loud) even if the pager never fired. Frame the stipend as payment for that constraint, not for incidents, and quiet weeks stop feeling like unpaid ones. Per-page models fail this test by design, which is why they work best as a supplement to standby pay rather than a replacement.

## Formalizing your on-call compensation

Pick the model that matches your team size, write the policy down, and automate the tracking before the first payroll dispute. If Opsgenie is your current on-call tool, the decision has a deadline attached: it reaches end of life on April 5, 2027, and our session on [what to do when Opsgenie sunsets](https://youtube.com/watch?v=ukOSqPaL5RE) walks through the migration path.

[Book a demo of incident.io](https://incident.io/demo) to see the compensation calculator running on a real rotation, from schedule to payroll export.

## Key terms glossary

**Standby pay:** A flat rate paid to an engineer simply for being available, sober, and near a laptop during an on-call shift. It compensates for the restriction on personal freedom rather than active work.

**Active incident premium:** Additional hourly or flat-rate compensation paid only when an engineer is actively resolving a paged incident. This keeps pay equitable during high-toil shifts.

**Salary-percentage hourly model:** An on-call pay structure where each engineer's hourly on-call rate is calculated as a fixed percentage of their annual salary. Because salaries differ, senior engineers earn more per on-call hour than junior engineers for the same work, which can create perceived inequity on mixed-seniority rotations.

**Waiting to be engaged:** An FLSA classification meaning the employee can use standby time for personal activities, so those hours are not compensable as work time. Response-time and location rules must leave the employee genuinely free for this to hold.

**Engaged to wait:** An FLSA classification where an employee's freedom is so restricted during standby that all hours count as paid work time. This applies when response windows are extremely short or the employee must remain on-site.

**Time-in-lieu (comp time):** A non-monetary model where engineers receive paid time off to offset hours spent on-call or resolving weekend incidents. For non-exempt staff in the private sector it generally cannot substitute for overtime pay, so track it carefully.