On-call compensation for startups: the complete guide to tracking hours and paying engineers

TL;DR: Informal, unpaid on-call models fail once your team grows beyond a handful of engineers, and the fix pairs a fair compensation model with automatic hour tracking, not spreadsheets. incident.io's own survey of on-call practitioners found 47% are paid for on-call, at an average weekly rate of $540. Monthly per-person payments reported by respondents ranged from $5 to $1,000, reflecting wide variation in rotation structure and company stage. Teams that have formalized a stipend typically pay $500 to $2,000 per month on broader industry benchmarks, plus 1.5x hourly pay for active incident resolution, with weekend on-call typically paying twice the weekday rate according to the same survey, and the Fair Labor Standards Act (FLSA) decides when restricted standby time counts as paid hours worked. This guide covers the models, the math, a copy-paste policy template, and how incident.io's Pro plan, $45/user/month with on-call ($25 base + $20 on-call add-on), tracks shifts in Slack and calculates payouts in one dashboard.

Informal on-call works until your team grows beyond a handful of engineers. "Whoever wakes up first handles the late-night alert" becomes a retention risk and a reliability problem. Formalizing compensation fixes both, and it does not require a legal retainer or a spreadsheet hobby. This guide walks through the models, the math, the policy template, and the tooling to run the whole thing inside Slack.

Justifying on-call pay to your founders

Your co-founders think in burn rate and runway, so frame on-call pay as risk mitigation with a number attached. A structured on-call program typically runs $500 to $2,000 per month per rotation, while one botched P1 during a strategic customer's evaluation can quietly kill that deal. Replacing a burned-out senior engineer costs even more once you add recruiting fees, onboarding time, and two quarters of lost product velocity.

The efficiency argument also lands well with non-technical leadership: Vanta automated a manual five-step incident process and now alerts the right people within minutes, which means fewer paid active hours and less chaos per page.

Signs it's time to formalize on-call

A few signals tell you the informal era is over: your engineering team has grown beyond a handful of people, customers are asking about uptime commitments in security reviews, and the founding team is still the unofficial safety net months after hiring. When you recognize these patterns, run this three-step transition:

1. Document the baseline: Track every alert that fires outside working hours for a period (two weeks is a good start), including who responded and how long resolution took.
2. Define the rotation: Set a weekly schedule with a primary and secondary responder, and write down the escalation path for missed pages.
3. Introduce the stipend: Launch a basic standby payment so availability is rewarded from day one, not negotiated later.

If you want benchmarks before setting rotation size, incident.io published research on how engineering teams structure rotations and pay. For a peer's view, watch our conversation with Isometric's CTO about rolling out formal on-call at a growing startup.

Core rules for equitable on-call pay

Whatever compensation model you choose, three principles keep it fair:

• Predictable: Engineers know the rate before they accept the shift, and the number does not change mid-rotation.
• Proportional: Pay tracks the actual burden, so a 1-in-3 rotation with nightly pages pays more than a quiet 1-in-6.
• Consistent: Many teams keep rates uniform across the same rotation regardless of seniority, avoiding the resentment that comes when two engineers carrying the same pager earn different amounts.

Hidden risks of informal on-call

The dangerous version of informal on-call is the silent kind: engineers half-watching Slack all weekend because nobody told them they could stop. That ambient obligation burns people out without producing a single logged incident, and it hits your strongest engineers hardest because they care enough to keep watching. By the time someone resigns, the exit interview is the first time leadership hears about it.

Calculating fair on-call rates

Three models dominate startup on-call pay, and most mature programs blend two of them:

Setting fixed-rate on-call stipends

The flat stipend is the default startup model because it is predictable for finance and simple to explain. incident.io's own survey of on-call practitioners found 47% of engineers are paid for on-call, at an average weekly rate of $540.

Monthly per-person payments reported by respondents ranged from $5 to $1,000, reflecting wide variation in rotation structure and company stage. The survey also found weekend on-call typically pays twice the weekday rate, which is the most reliable first-party basis for a 2x figure in rotation design. Salary aggregator data from devopssalary.com, which draws on self-reported figures from Glassdoor, Levels.fyi, and similar sources, puts formalized flat monthly stipends higher, at $500 to $2,000 per month, scaling by rotation intensity and incident volume as teams grow.

One warning: a stipend that works out to a few dollars per hour of restricted freedom reads as a token gesture, and token gestures damage morale more than paying nothing while you design a real policy.

Setting hourly standby rates

Hourly standby pay starts from the engineer's base rate. The average DevOps engineer salary in the US is around $130,000 to $140,000, and startups typically pay standby at a modest percentage of that base rate.

The math exposes the trade-off fast. Full 24/7 coverage is 168 hours per week, so pure hourly standby can become expensive quickly, which is why most startups reserve hourly standby for part-week coverage and use flat stipends for full rotations.

Paying hourly for active incident resolution

Active resolution is real work, and the market prices it that way. SHRM data shows companies that pay overtime for on-call time typically pay hourly, non-exempt technical employees 1.5x their standard hourly rate. Some programs go to 2x for the highest-severity pages, though that sits above the documented benchmark. Salaried exempt engineers have no legal overtime entitlement, but most startups apply the same rate structure by policy choice. At that range, an engineer earning $72 per hour who spends 90 minutes on an after-hours page earns $162 to $216 for that response.

Many teams add a minimum payment per page, because a brief page that ruins an hour of sleep should not pay only a few dollars.

Mixing shift pay with incident fees

The hybrid model pairs a modest stipend with per-incident pay: for example, a weekly stipend for carrying the pager, plus an hourly rate for active resolution. A week with multiple after-hours incidents pays the stipend plus the hourly fees, and a quiet week still pays the base stipend.

This structure aligns incentives cleanly. Availability is always rewarded, extra effort during bad weeks is compensated, and pairing the incident fee with mean time to resolution (MTTR) goals keeps resolution speed honest.

Aligning pay with team maturity

Compensation is not set-and-forget. Review your incident volume regularly: divide the stipend by the actual active hours your rotation logged, and if the effective rate has drifted below your target, raise the stipend or rebalance the rotation. A policy that was fair at five incidents a month becomes underpayment at twenty, and your engineers will run this math even if you do not.

The other lever is shrinking the active hours you pay for. Investigations, our AI SRE product, automates up to 80% of incident response, getting teams from alert to resolution an order of magnitude faster, which cuts the active-resolution bill directly.

Tracking on-call shifts automatically

Writing the policy is the easy part. Tracking who was actually on-call, who the system paged, and who swapped shifts is where compensation programs quietly die, usually in a spreadsheet nobody owns.

Avoiding manual errors in on-call pay

Manual tracking fails in predictable ways: engineers forget to log the after-hours page, a shift swap lives only in a DM thread, and finance reconciles a month of guesses.

Automating your on-call pay calculations

incident.io's Pro plan includes the compensation calculator alongside escalation paths, and the on-call pay report provides a quick and easy way to pull compensation for your on-call responders without having to manage internal tooling and scripts. The platform knows who held the pager and when shifts changed, so the report does the shift arithmetic you would otherwise do by hand. Active-resolution hours still go to payroll separately. Customers already run this in production:

"I really love the slack integration, the automated summaries and the On Call pay reports feature." - Verified user on G2

Capturing incident timelines without manual entry

The tracking flow runs where the work happens. When a Datadog alert fires, incident.io auto-creates a Slack channel, pages the on-call engineer, and starts the timeline. When the responder resolves the incident with /inc resolve, the platform captures the resolution time automatically, with no manual entry required. That resolution time lands in the incident timeline, which is where you pull active-resolution hours from when you calculate the incident fee.

Setting up paid on-call tracking

Setup lives in incident.io's web dashboard: define your rotation, set your hourly or daily rates and the hours they apply to, and the schedule syncs to Slack, where responders acknowledge pages with /inc. Infrastructure-as-code teams can manage the configuration through our Terraform provider instead of clicking through the UI. One reviewer who migrated onto the platform put the setup experience plainly:

"...it was easier to set up than equivalent products, and the support team... made our migration smoother by driving the process." - Wael N. on G2

You can test basic scheduling on the free Basic plan, though escalation paths and the compensation calculator require Pro with the on-call add-on. For a feel of the product before any of that, watch this hands-on Catalog tour or hear WorkOS's VP of Engineering describe his team's most-used features.

Paying engineers accurately for on-call time

Tracking hours is only half the job. The other half is getting money from your bank account into paychecks without a monthly reconciliation chore.

Automating payroll for on-call hours

The output of your on-call tracking tool has to reach payroll in a shape finance can use. The practical version for a startup is a clean CSV export of on-call hours and rates. Most payroll systems support a CSV upload for one-off payments and additional wages, though confirm the format yours expects before you build the export around it. incident.io's pay report can export data for this process.

Updating payroll for mid-month changes

Startups swap shifts constantly: vacations, sick days, an engineer who cannot take another page this week. Each swap changes who earned what, and tracking it in DMs fails exactly when you need it.

Because incident.io treats the schedule as the source of truth, an override in the dashboard or Slack updates the pay report automatically, and incident.io pays the correct engineer for the exact hours they covered.

Defining clear on-call payout rules

Getting the mechanics right matters less than getting them written down. This section covers the rules that define what counts as a paid incident, how to draft the policy itself, and how to introduce it to your team.

Deciding what counts as a paid incident

Write down three things before anyone carries the pager: what qualifies as a paid incident (many teams use P0 and P1 events, not every warning alert), the acknowledgment expectation (many teams use 30 minutes as a practical starting point), and the escalation path when the primary responder misses a page. Missed pages happen for mundane reasons, and automatic escalation to a secondary responder covers those human failure modes.

Your policy should clarify whether escalated secondary time earns the active rate, and many equitable programs choose to compensate it.

Drafting your on-call compensation policy

Here is a starting template you can adapt:

[Company Name] On-Call Compensation Policy

1. Purpose
This policy defines the compensation and expectations for engineers participating in the [Company Name] on-call rotation.

2. Definitions
- Emergency Incident: A high-severity event (such as P0 or P1) causing system downtime, data loss, or severe degradation affecting multiple customers.
- Non-Emergency Incident: A lower-severity event (such as P2 or P3) that can be resolved during regular business hours.
- Standby Time: The period an engineer is designated as the primary or secondary responder and must remain available to respond to alerts.
- Active Resolution Time: The time spent actively troubleshooting and resolving an Emergency Incident.

3. Compensation
- Standby Stipend: Engineers receive a flat stipend per week of on-call standby duty [specify amount].
- Active Resolution Pay: Engineers are compensated at [specify rate] per hour (minimum 1 hour per incident) for time spent resolving Emergency Incidents outside regular business hours.

4. Expectations
- Primary responders must acknowledge critical alerts within [specify timeframe].
- If an alert is not acknowledged within [specify timeframe], it will automatically escalate to the secondary responder.

Treat this as a starting point: adjust the rates and definitions for your rotation, and have your counsel check the final version against the states where your engineers work.

Introducing the new on-call rules

Roll the policy out with the math visible. Share the benchmark data you used, state the quarterly audit commitment, and invite feedback for the first 30 days. Engineers trust a policy they can check, and the fastest way to sour a rollout is a rate that appears from nowhere with no reasoning attached.

Calculating your team's first on-call pay

Running the numbers before anyone gets paid protects your program from errors that are hard to walk back. Here is how to structure the first cycle, handle any backpay obligations, and avoid the mistakes that stall new programs.

Planning your first on-call cycle

Run the first cycle as a dry run: track hours and calculate what everyone would have earned, but do not run payroll against it yet. The dry run surfaces scheduling conflicts, tests your escalation path, and gives engineers a payslip preview they can sanity-check before real money moves.

Settling outstanding on-call pay

If engineers carried informal on-call before the policy existed, decide explicitly how to handle it. A one-time transition payment or retroactive stipend buys real goodwill and signals the policy is a commitment, not a cost-control exercise. Whatever you choose, announce it in the same breath as the policy itself.

Avoiding common on-call pay mistakes

Three mistakes sink new programs:

1. Ignoring alert fatigue: Paying per incident means nothing if half the pages are noise, so tune your rules with alert filtering and rate limits before you tune rates.
2. Freezing the stipend: Incident volume grows with your customer base, and a stipend set at five incidents a month is underpayment at twenty.
3. Forgetting the secondary: Responders who get escalated to did the work, and excluding them from active pay teaches people to let pages ring.

Estimating on-call costs for startups

Here is the budgeting math for one full 24/7 rotation:

Tooling adds a modest line item by comparison: incident.io's Pro plan can support your rotation alongside scheduling, escalation paths, and compensation tracking, replacing the spreadsheet, the paging tool, and the payroll reconciliation chore in one line item.

Addressing on-call fairness and pay concerns

Fairness is not just a morale question. It has legal dimensions that vary by state and employment classification. This section covers the compliance requirements, how overtime interacts with on-call pay, and how to supplement cash compensation with time off.

Ensuring legal on-call pay standards

Federal law draws the compensability line with two phrases you need to know. Under the FLSA, an engineer who is "engaged to wait" is on duty and their time is hours worked, while one who is "waiting to be engaged" is off duty. The practical test is freedom: if an engineer can use standby time for personal activities, it is generally not compensable, but tightly restricted standby is typically treated as work.

This is why response-time expectations belong in the written policy. The FLSA sets no bright-line minute threshold, but many teams use a 30-minute acknowledgment window as a practical threshold for staying in "waiting to be engaged" territory.

Shorter windows increase that risk: some case law under the FLSA and its progeny points to windows of roughly 15 to 20 minutes or less as the range where regulators are more likely to reclassify standby time as "engaged to wait," since they significantly limit the engineer's ability to use idle time for personal purposes. No federal regulation sets a precise minute threshold, so treat 15 to 20 minutes as a caution zone rather than a legal bright line.

Meeting legal requirements for on-call pay

Federal FLSA rules are the floor, not the ceiling. California goes further: on-call employees required to remain at or near the workplace may be entitled to reporting time pay, and a 2019 Court of Appeal decision extended that exposure to call-in shifts where employees never physically arrive, though the ruling addressed the mercantile wage order and its reach into tech has not yet been tested.

The controlling question is how much the employer restricts the employee's time, and California law is generally more demanding than federal law on this point. California's control test can require pay for on-call time the FLSA would leave uncompensated. If you have engineers in California, write the policy to the stricter standard.

Handling overtime for non-exempt engineers

For non-exempt engineers, active resolution hours count toward the 40-hour workweek, and federal overtime rules require at least 1.5x the regular rate for every hour past 40. A long incident weekend can push a non-exempt engineer over the line, so your pay report needs to flag cumulative weekly hours, not just per-incident totals.

Managing exempt staff on-call pay

Most startup software engineers are salaried and exempt, which means no legal overtime entitlement, because the computer professional exemption covers software engineers paid above the FLSA salary threshold. Exempt is not the same as free, though: employers may choose to compensate exempt staff for extra hours, and a stipend is precisely that choice, made in writing. The retention math from the first section is why you pay them anyway.

Managing comp time for engineers

Cash is not the only currency. Many startups add comp time: time off for weekend on-call shifts, or a late start the morning after a night page. Comp time works best as a supplement to the stipend rather than a replacement, because time off does not pay rent, and it only counts if managers let people take it.

Tracking on-call pay without a spreadsheet

Fair on-call pay comes down to three things: a compensation model your engineers can predict, accurate hour tracking that doesn't rely on memory or DMs, and a policy written down before the first dispute happens. Get any one of those wrong and the other two stop mattering: an accurate stipend calculated from a guessed schedule is still a guess. Your compensation policy is only as reliable as the data behind it, and manual tracking is where good policies go to die.

Book a demo of incident.io and see on-call scheduling and escalation paths running in Slack, with the compensation calculator handling payout in one dashboard.

Key terms glossary

Standby time: The designated period an engineer must remain reachable and ready to respond to production alerts, usually compensated via a flat stipend.

Active resolution time: The actual hours an engineer spends troubleshooting and fixing a critical incident after being paged, typically compensated at an hourly premium rate.

Engaged to wait: A legal classification under the FLSA where an employee's standby time is so restricted that they cannot use it for personal activities, requiring full compensation for all hours.

Waiting to be engaged: A legal classification under the FLSA where an employee on standby has enough freedom to pursue personal activities, so the standby hours are not legally compensable work hours.