On-call is the part of an SRE, DevOps or platform job that the offer letter says least about, and it's the part most likely to decide whether you still want the job a year later. Salary, level and title all get negotiated in writing. The rotation usually gets one line in the job description ("participation in an on-call rotation") and a reassuring sentence from the hiring manager.
Most of what you need to know about a team's on-call can be found out before you sign, if you ask the right questions and listen carefully to how they're answered. This is the list I'd take into the last round.
Asking Without Sounding Like You're Dodging the Pager
The worry that stops most people asking is that it'll read as "I don't want to do on-call." In practice it reads the other way. Engineers who've carried a pager for a while ask specific questions about it; people who haven't tend to ask nothing, or ask whether there is one at all. When I wrote about what SRE interviews are actually testing for, the argument was that the differentiator has moved from debugging speed to judgment, and a sharp question about alert volume shows judgment as well as most of the answers you'll give in the loop.
Timing matters more than phrasing. A recruiter usually can't answer any of this. Save it for the hiring manager, and if you can, for an engineer who is on the rotation right now. Frame it as wanting to understand the work: "What does a typical on-call week look like for this team?" gets you further than "How bad is on-call?"
How Many Times Did the Last Person Get Paged?
Ask about a specific recent shift, not the average. "How many pages did whoever was on-call last week get, and how many of them were overnight?" An average smooths over the week that ruined someone's sleep, and "it varies" tells you nothing.
There's a useful benchmark to hold the answer against. Google's SRE book, in its chapter on being on-call, works out that dealing with one incident properly (root cause, remediation, the postmortem) takes about six hours, and concludes that "the maximum number of incidents per day is 2 per 12-hour on-call shift." It also says the median should be zero: most shifts should be quiet. That's a ceiling Google wrote for its own teams, not a law, but it gives you something concrete to compare against, and a team fielding five pages a night is well past it.
What you're also listening for is whether they know the number at all. A manager who can say "about three pages a week, mostly from one flaky dependency we're replacing" has a team that measures its pain. One who has to guess probably doesn't, and pain nobody measures rarely gets fixed.
How Big Is the Rotation?
This one is just arithmetic, and it's the question people most often forget to ask. With four people sharing a weekly rotation you're on-call one week in four, every month, for as long as the team stays that size. With eight it's one in eight.
The same Google chapter derives its minimums from a rule that no more than 25% of an SRE's time goes on on-call: "the minimum number of engineers needed for on-call duty from a single-site team is eight," covering a primary and a secondary, and "a reasonable minimum size of each team is six" when two sites split the day between them. Most teams you'll interview with are smaller than that, and that's fine if the service is quiet. It's less fine when a small rotation meets a noisy service.
Two follow-ups are worth asking here. Is there a secondary, so you're never the only person between an alert and an outage? And if the team spans time zones, is it genuinely follow-the-sun, or does one region cover nights because it's smaller?
What Happens to an Alert That Pages for Nothing?
This is the question that separates a rotation that's bad today and getting better from one that's bad and staying bad. Every team has noisy alerts. What matters is whether anyone is allowed to spend time fixing them.
Google's guidance is short: "All paging alerts should also be actionable." The same chapter warns that low-priority alerts firing every hour cause fatigue that "can also cause serious alerts to be treated with less attention than necessary", which is the quiet way most alerting failures happen (I went into one version of it in The Hidden Cost of Green Dashboards).
So ask for an example: "When did the team last delete or retune an alert, and who decided?" A good answer names a recent alert and a person. A worrying answer is that alerts are owned by another team, or that tuning happens "when we get time", which usually means it doesn't happen.
Whose Code Are You On-Call For?
On a platform or central SRE team, you can end up carrying the pager for services written by people who've never been woken up by them. That isn't automatically bad, but it changes everything about whether the rotation can improve.
Ask what happens when a service another team owns is paging too much. Google's answer, again from the same chapter, is that in extreme cases SRE can "give back the pager," asking the developers to be on-call for their own system "until it meets the standards of the SRE team in question." Very few companies have that lever written down. What you want to hear is that something like it exists, even informally: a way to push reliability work back onto the team that's generating the pages. If the honest answer is "we just absorb it," you'll be absorbing it too.
Is It Paid, and What Happens After a Bad Night?
Ask about pay directly, and don't read too much into the answer on its own. Gergely Orosz's overview of how more than 120 firms handle it at The Pragmatic Engineer, Oncall Compensation for Software Engineers (2022, so treat the specifics as dated), found that "Most of Big Tech don't pay for oncall with cash compensation. Google is the only exception." He also observed that "The more an employer compensates software engineers, the more likely they expect oncall to be a given." An unpaid rotation at a top-of-market salary is a different deal from an unpaid rotation at an average one. Some countries also regulate on-call pay and rest, so where you'll be employed matters as much as where the company is based.
The question I'd weight more heavily is the informal one: if you're up from 2 a.m. to 5 a.m. fixing something, are you expected online at 9? Teams that tell you to start late, or take the morning off, without anyone needing to ask, usually treat on-call as real work in other ways too. Teams where that question gets an awkward pause usually don't.
Reading the Answers
Nobody will describe their on-call as terrible in an interview, so what you're judging is how specific the answers are. Numbers, names and recent examples are good signs even when the numbers are bad, because a team that knows exactly how noisy it is can usually tell you what it's doing about it. Vague reassurance, or a manager who answers every question and then won't let you talk to someone on the rotation, is the pattern to worry about.
Bad on-call isn't automatically a reason to turn an offer down. A noisy rotation with a funded plan to fix it, and a manager who can point to the last three alerts they killed, can be a great place to learn this work fast. If you join one, the AI agents now landing in on-call tooling may take some of the triage off you, though they won't fix a rotation that's understaffed. What you want to avoid is the version where nobody knows the numbers and nobody has time to change them.
You'll put more effort into negotiating your salary than any of this. It's still worth twenty minutes in the last round, since you'll be living with the answers every few weeks for as long as you're there.