The On-Call Experience Ranked by Company Type
Company structure sets your on-call burden far more than team culture or how hard you work.
Engineers treat on-call as a condition of work they will manage when it arrives. That instinct is the problem. On-call burden is set by company structure before you sign the offer, and the tier you join determines the load more than team culture, your manager, or how hard you work.
Why the company type you join determines your on-call experience more than any other factor
A backend engineer at a five-person startup and a backend engineer at a large public tech company are not doing the same job with different perks. They are in different structural situations. The gap in on-call burden between those two roles is not cultural. It is a function of rotation depth, tooling maturity, ownership concentration, and staffing ratios, all of which are determined by company structure. How many engineers share the pager decides whether a 2 a.m. page interrupts your sleep twice a month or twice a night. The tooling budget decides whether that page carries a clear runbook or an open-ended scramble.
The consequences of getting this wrong are larger than most engineers assume. The site goes down at 2 a.m. and they learn more about infrastructure in six months than in two years elsewhere. When it is unhealthy, it quietly corrodes everything that makes engineering teams effective. On-call is also increasingly a hiring signal. A strong senior ML engineer is now defined in part by having shipped models to production and owned on-call responsibility. Engineers who understand on-call regimes before they join are better positioned to negotiate and evaluate offers. This piece ranks each tier honestly so you can factor on-call into your next career decision with clear eyes.
What makes on-call hard: the mechanisms that drive burden across every tier
On-call burden is produced by a small set of structural mechanisms. Understanding them is what makes a tier comparison legible rather than a list of impressions. The first mechanism is ownership concentration, and it is the primary driver of burden at small companies, not traffic volume or system complexity. When the same engineer owns the service, the deploy pipeline, the database, and the incident, there is no rotation to absorb the load. Every page lands on the same person who built the thing that broke.
Alert fatigue is the most direct driver of on-call burnout across all tiers. It is a systems design failure, not a morale problem. The Google SRE Workbook sets a sustainable baseline of a maximum of two actionable incidents per shift. That target requires deliberate investment in alert hygiene that under-resourced teams cannot make. Poorly tuned alerts wake engineers for non-urgent conditions until the pager becomes noise, and then real incidents get missed inside the noise.
Rotation depth is a staffing math problem. Google's SRE philosophy derives from its on-call rules a minimum of eight engineers needed to sustain a primary-plus-secondary rotation from a single site. Most startups simply cannot reach that number. With fewer engineers, primary rotations fall more often, and the secondary rotation may not exist at all. Remote distribution compounds this variable rather than resolving it. Follow-the-sun scheduling applies only when teams span enough time zones, meaning smaller organizations rarely benefit from it. Remote-native scaleups that architect for global distribution from the start, such as Supabase, born fully remote in 2020, can build an on-call advantage over co-located startups without comparable headcount.
The metric that cuts across every tier is sleep disruption rate, the number of overnight pages between midnight and 6 a.m. per rotation period. It most directly predicts burnout. More than two to three overnight pages per week, sustained, is unsustainable at any company tier. The tier you join determines how likely you are to live inside that loop.
Large public tech companies: structured rotations, but pressure calibrated to stakes
Large public tech companies offer the most structured on-call regimes in the industry. The consequence of being wrong scales with the size of the user base. At FAANG companies, engineers have clear work hours, established on-call rotations, adequate staffing, and respect for personal boundaries outside of launch periods. Those are the structural conditions that make sustainable on-call possible. The rotation exists because enough engineers exist to fill it.
The strongest objection to the claim that big tech on-call is easier deserves a serious answer. FAANG on-call is not inherently easier. It is differently high-stakes. An engineer at a global platform is not worried about whether the company survives the night. They are worried about whether a latency spike in one region becomes a public outage story by morning.
The structural answer to high stakes at large companies is investment, in tooling, in rotation depth, in SRE specialization, in runbooks. The burden per engineer is still lower even when the consequence per incident is higher, because the load distributes across a deep rotation and the runbook exists before the page arrives. Work-life balance at Big Tech is generally good, around 40 to 50 hours per week, though it varies by team and product. A comfortable platform team and a high-visibility product team can feel like different employers when the pager fires.
Scaleups and late-stage private companies: professionalizing on-call, but not yet formalized
Scaleups are professionalizing their on-call practices, but without the depth of Big Tech staffing or the simplicity of a small startup. The on-call experience at this tier is the hardest to predict before you join. Teams at this stage, roughly Series B through E, spanning hundreds to thousands of employees, are large enough to build real rotations but small enough that platform and SRE specialists remain scarce. The gap between a smaller company and a larger one within this tier is enormous.
Anthropic at approximately 3,000 to 5,000 people and Sierra at 200 are both called AI startups. You get bureaucratic overhead on top of startup-level rotation thinness. Incident reports with owners and severity levels, but the same two engineers on every page.
The opposite is also possible. Certain remote-native scaleups that distribute teams across multiple time zones from the start, like Supabase, born fully remote in 2020, can build follow-the-sun on-call coverage. Ask how many engineers are in the rotation, how often primary on-call falls, and whether there is a secondary rotation. Those three numbers reveal the actual burden before the offer letter is signed. A six-person rotation with no secondary tells you more than any conversation about engineering culture.
Early-stage startups: broad ownership and fast learning, with on-call as the cost of admission
At early-stage startups, on-call is not a rotation. It is a condition of ownership. That ownership is the most compelling thing about the role and its most significant hidden cost. You touch systems that would be walled off behind a platform team at a larger company.
The learning proposition at its best is real. Engineers describe deploying to production on day one at a five-person company and learning more about infrastructure in six months than in two years at a large company, because the site went down at 2 a.m. and they were the only one awake. The structural problem is that ownership concentration means there is no rotation to distribute the load. The psychological effect of being always on rapidly impacts team health, and founders risk losing founding team members over preventable on-call failures.
On-call compensation at early-stage companies rarely reflects the actual burden. The problem is large enough to support a dedicated market. On-call tooling at the startup tier is a category-level problem.
Founding engineer roles: on-call as a total-ownership condition, not a job feature
The founding engineer role is the only tier where on-call, technical PM, customer escalation, and architecture ownership all collapse into a single person. This condition is not an edge case. It is the structural definition of the role. There is no secondary rotation because there is no secondary engineer.
The seed-stage median team is just four employees, so the first engineer shapes everything. Systems design decisions made under on-call pressure in week two become the architecture the company runs on for the next three years. That is a genuinely consequential position. Equity is the implicit argument for absorbing the total burden, which makes equity evaluation, including dilution, exercise windows, and exit probability, inseparable from evaluating the on-call trade-off. The right question is not whether the burden is acceptable. It is whether the equity outcome can justify the total ownership. The argument is that they should enter with full knowledge of what the on-call condition actually means at this tier, not that they should avoid it.
How burnout risk accumulates differently across the tiers
Burnout from on-call is not a personal failure. It is a predictable output of the structural conditions at each tier, and the risk profile is set largely before you start the job. Software engineer burnout in the US tech sector has reached a significant rate, driven by sprint culture, always-on incident response, and blurred remote work boundaries. When the rotation is one person deep, losing that person is an existential infrastructure event, not just a staffing problem, because the system knowledge leaves with them.
The burnout risk at large tech companies is real but differently structured. The metric that cuts across tiers is the same one. Sleep disruption rate, the number of overnight pages per rotation period, is the single most direct predictor of sustained burnout regardless of company size. The structural conditions at each tier determine how often that number exceeds a sustainable threshold. You are choosing the rate of 2 a.m. pages your life will tolerate.
What AI and ML engineers need to know about on-call that software engineers often don't
The ML engineer's role has shifted from building models to owning them in production. Skill requirements now overlap substantially with MLOps and software engineering rather than pure research. That shift is a direct on-call burden increase. Production ownership means pager ownership.
On-call responsibility has become a hiring signal at senior levels. A strong senior ML engineer is now defined in part by having shipped multiple models to production, owned on-call responsibility, and made significant technical decisions within their team. The market understands this. AI research engineer searches at non-frontier startups grew meaningfully year-over-year in 2025 data, with talent moving from academia and large platform companies. Time-to-fill is long partly because research engineers negotiating these roles increasingly scrutinize on-call terms alongside equity. At a founding-engineer-equivalent AI role, owning a production model means owning every degradation event, every inference latency spike, and every data pipeline failure at 2 a.m. A model silently drifting into degraded performance does not.
The tier question for ML engineers is sharper than for generalist software engineers. The same person who designed the model architecture is waking up to diagnose the inference latency spike. The tier label matters for ML engineers in a way it may not for engineers whose systems have decades of operational precedent behind them.
How to use the tier framework when evaluating an offer
The tier framework is only useful if you know what to ask before signing an offer. What is the average number of overnight pages per on-call week over the past quarter? Every engineering manager should be able to answer these from their incident data. An unwillingness to answer is itself information.
At early-stage startups and founding engineer roles, also ask how on-call is acknowledged in compensation or time policy. If there is no answer, that is an answer. For ML and AI engineering roles specifically, ask whether the model serving infrastructure has dedicated SRE coverage or whether the ML engineer owns production incidents end-to-end. A company's tier sets the prior probability for each on-call condition: rotation depth, tooling maturity, and alert hygiene investment. The due diligence questions above are how you update that prior with actual evidence from a specific employer. A scaleup can answer the three questions well and beat the tier average. A large company can answer them poorly and disappoint the baseline.
Engineers who factor on-call into their career decisions with structural clarity are better positioned to choose the tier that matches their career goals, risk tolerance, and life outside work. This is not a cautionary tale. The structural realities of on-call at each tier do not change because of a good recruiter, a compelling mission, or a strong first conversation with the engineering manager. They change only when you apply the right questions to the right tier. Knowing the structure gives you the leverage to make an informed decision rather than an anxious one. The 2 a.m. pages will come. Whether they come twice a quarter or twice a night is a knowable fact before you accept the offer.
