On-Call Is the Part of Engineering Nobody Negotiates

The Second Job You Don't Get Paid For

The total compensation for a software engineering role is not fully captured by salary, bonus, and equity. A significant and often overlooked component of the job is the on-call rotation, a responsibility that can function as a second, uncompensated job with a material impact on your life. Engineers routinely scrutinize every dollar of their base pay and every vesting cliff on their stock options, yet they accept on-call duties as a simple, non-negotiable fact of the profession. This is a costly mistake. The difference between a well-managed rotation and a poorly managed one can be the equivalent of a twenty percent pay cut, a chronic sleep debt, and a constant state of low-grade anxiety. Two engineers at the same level with identical $180,000 salaries can have vastly different realities. One might be on-call once every eight weeks, get paged twice during that week for manageable issues, and receive a stipend. The other might be on-call every fourth week, get woken up multiple times a night, and receive no additional pay. Their titles and salaries are the same, but their jobs, and their effective hourly wages, are not even in the same league. Understanding the mechanics and hidden costs of on-call is not just about quality of life; it is a fundamental aspect of evaluating a job offer. This responsibility represents a direct transfer of business risk from the company to the individual engineer, and it deserves the same level of scrutiny as any other line item in your employment agreement.

Rotation Size Dictates Your Freedom

The most immediate factor determining the burden of an on-call rotation is its size. The number of people sharing the load directly dictates how frequently your life will be interrupted. A small team of three engineers means you are tethered to your laptop and within five minutes of a stable internet connection for one week out of every three. This is an unsustainable, burnout-inducing pace. A weekend is no longer a break; it is a 48-hour window of elevated alert. Dinner plans, family outings, and even a trip to the grocery store are contingent on carrying a pager and a laptop. In contrast, a team with eight or more engineers on its rotation pushes that frequency out to once every two months. This is a manageable, professional commitment. The difference is not incremental; it is a categorical shift in the nature of the job. A healthy rotation should have a minimum of six engineers, with eight being a much more stable and resilient number. Any team with five or fewer members sharing primary on-call duties is a major red flag, indicating either understaffing or a fundamental misunderstanding of operational sustainability. When interviewing, it is critical to understand that this number is not static. A team of seven can shrink to a team of five in a single quarter due to attrition. Asking about the historical size of the rotation and the forecast for team growth provides crucial context. A hiring freeze can turn a comfortable rotation into a grueling one within six months, a risk you implicitly accept if you do not inquire about it.

The Signal-to-Noise Ratio of Your Pager

Not all on-call weeks are created equal. The sheer volume of pages is just as important as the frequency of the rotation. Being on-call for a stable, mature system might mean handling one or two legitimate, service-impacting incidents during your seven-day shift. Conversely, being on-call for a brittle, poorly instrumented system can mean a constant barrage of alerts, many of which are meaningless noise. This is the difference between being a firefighter and being a person who lives inside a building with a faulty smoke detector. A constant stream of low-priority or non-actionable alerts creates a phenomenon known as alert fatigue. Engineers become desensitized to the pager, leading to slower response times when a truly critical incident occurs. It also destroys any chance of having a restful period, as the mind is never allowed to fully disengage from work. A healthy on-call system respects the engineer's time and attention. Its alerts are high-signal, infrequent, and directly tied to a potential business or customer impact. A dysfunctional system uses the on-call engineer as a human filter for its own chaotic monitoring. As a candidate, you must probe this aspect with precision. Do not ask a generic question like "Is it noisy?" Instead, ask for hard numbers. A powerful question is, "Over the last completed on-call rotation, how many pages were acknowledged by the primary engineer between 5:00 PM on Friday and 9:00 AM on Monday?" If the hiring manager cannot answer this or a similar data-driven question, it suggests the team does not even track its own operational burden, a significant warning sign. Anything more than five pages over a weekend indicates a problem that will directly affect your life.

The Three Models of On-Call Compensation

While many engineers treat on-call as an unpaid obligation, there are distinct compensation models that can and should be part of your negotiation. The most common and least favorable model is that on-call duty is simply an expected part of a salaried, exempt role. Under this arrangement, the hours spent troubleshooting a production outage at 3:00 AM are compensated at a rate of zero dollars. This model effectively lowers your real hourly wage and socializes the cost of system instability across the engineering team. It is pure, uncompensated labor. A more equitable arrangement is the flat-rate stipend. In this model, the engineer assigned to the primary on-call rotation receives a fixed bonus for the week. This payment recognizes that being on the hook, even if no incidents occur, represents a significant constraint on personal freedom. A typical stipend for a primary rotation at a mid-sized tech company can range from $500 to $1,500 for the week, with secondary on-call often receiving a smaller amount. For a senior engineer earning $200,000, an extra $1,000 for one week of on-call every eight weeks adds $6,500 to their annual income, a non-trivial 3.25% increase. The third model, often found in more mature or heavily regulated industries, involves getting paid an hourly rate for time actively spent resolving an incident. This is frequently calculated at 1.5 times the engineer's effective hourly rate. This model directly ties compensation to the pain of the work, creating a powerful financial incentive for the company to invest in stability and reduce incident volume. Failure to inquire about the compensation model is a silent concession, potentially leaving thousands of dollars and countless hours of free labor on the table.

The Unseen Tax of Sleep Interruption

The cost of a difficult on-call rotation cannot be measured in money alone. The biological price of interrupted sleep is a debt that compounds over time, impacting cognitive performance, mental health, and long-term physical well-being. Being paged at 2:00 AM is not merely an hour-long interruption. The adrenaline surge from a critical alert, the blue light from the screen, and the mental effort of debugging a complex system can make returning to restful sleep impossible. A single night of broken sleep can impair cognitive function the next day to a degree equivalent to being legally intoxicated. For a software engineer, this translates to a higher likelihood of introducing bugs, poorer decision-making in system design, and reduced creative problem-solving capacity. Companies that fail to acknowledge this reality are not only harming their employees but also sabotaging their own product development. A key differentiator between a modern, sustainable engineering culture and an archaic, exploitative one is the policy regarding post-incident recovery. A responsible organization will have a clear rule: if you are up for more than two hours overnight dealing with an incident, you are not expected to be online for morning meetings. You are encouraged to sleep in and sign on later in the day, without needing special permission or using paid time off. Conversely, a culture that celebrates "heroics" and expects an engineer to be at their desk for a 9:00 AM stand-up after being awake half the night is actively promoting burnout. This is a critical point to clarify before accepting an offer. The absence of a formal recovery policy is, in itself, a policy of ignoring the human cost.

Escalation Policies Are Your Only Safety Net

No on-call engineer should be an island. A well-designed incident response process is built on the principle of layered support, not individual heroism. The escalation policy is the single most important document protecting the on-call engineer from burnout and ensuring that incidents are resolved efficiently. When you are paged for an issue that is beyond your expertise, or if you have been working on a problem for over an hour without resolution, what happens next? A healthy system provides a clear, no-fault path to bring in reinforcements. This typically involves a designated secondary on-call engineer who can provide a second set of eyes, followed by a subject matter expert or a staff-level engineer if the problem persists. The culture of the team is paramount here. If escalating is viewed as a sign of failure or incompetence, engineers will struggle in silence, extending outage times and increasing their own stress. The ability to escalate without judgment is a hallmark of a high-functioning team. A robust policy also includes a path to wake up engineering leadership. For a severe, business-critical outage, the on-call engineer must have the authority and the obligation to escalate to a manager or director who can coordinate a wider response, manage communication, and make executive decisions. This protects the engineer from bearing the full weight of a crisis alone. Before joining a team, you should ask to see the escalation policy. If one doesn't exist, or if it's vague, you are looking at a future where you are the sole backstop for failure, a lonely and unsustainable position.

The Myth of "Follow the Sun" and True Incident Load

Not all services are created equal, and therefore, not all on-call rotations bear the same burden. A team managing a legacy batch processing system that runs overnight will have a very different on-call experience than a team managing a tier-one, customer-facing API with stringent uptime requirements. The nature of the service dictates the likely frequency, timing, and severity of incidents. It is essential to understand what, exactly, you will be supporting. Are you on the hook for the core login service, or a less critical internal analytics dashboard? The answer dramatically changes the risk profile of your on-call week. Furthermore, many global companies tout a "follow the sun" support model, where on-call responsibilities are handed off between teams in different geographical regions to ensure 24/7 coverage without overnight work. While this is an excellent model in theory, its implementation is often flawed. For this to work, there must be deep expertise and true ownership of the service in each region. More commonly, a service is primarily owned and understood by a single team in one location. When an incident occurs in another time zone, the local team may perform initial triage, but they will inevitably escalate back to the core team in North America, waking you up regardless of the "follow the sun" policy. This is especially true for highly specialized or new services where knowledge has not yet been disseminated. You might find you are the de facto global expert, making your on-call rotation a 24-hour liability, not an 8-hour one. Asking who the last three off-hours escalations came from can reveal the truth behind the promise of a global support model.

Questions That Pierce the On-Call Veil

To properly evaluate the on-call component of a job offer, you must move beyond vague inquiries and ask pointed, data-driven questions during your interviews. Your goal is to uncover the ground truth of the team's operational health, which is often glossed over in the hiring process. Treat this conversation with the same seriousness as you would a discussion about your equity package. The answers will determine a significant portion of your work-life balance and, in some cases, your effective compensation for the next several years. Incorporating specific, well-formulated questions demonstrates your seniority and your understanding of what it takes to build and maintain resilient systems.

This week, whether you are actively interviewing or simply assessing your current role, start by gathering data. For prospective roles, select two or three of the following questions to ask your potential manager or teammates: "How many engineers are on the primary rotation, and has that number changed in the last six months?" "What is the compensation for on-call duties—is it included in salary, a stipend, or hourly?" "Can you describe the team's policy for taking time off after a major overnight incident?" "What was the total number of pages outside of business hours for the primary on-call last week?" Finally, and most critically, "Can you walk me through the full escalation path, including when management gets involved?" The clarity and confidence of their answers are as important as the answers themselves. If you are currently in a role with a painful rotation, begin tracking these metrics yourself. Document the page volume, the hours you spend working on incidents, and the nights your sleep is disturbed. This data is not a list of complaints; it is the foundation for a professional, data-backed conversation with your manager about investing in system stability, fair compensation, and a sustainable engineering culture.