Cloud engineers are, as an industry, remarkably good at calculating infrastructure costs to the penny. Spot instance pricing, reserved capacity discounts, egress fees at three in the morning: the numbers get scrutinised. Yet many of those same engineers are donating thousands of pounds of their own time every year without a second thought. The apps were installed during onboarding. The expectation formed on its own. Nobody ever said it was a requirement, because nobody ever needed to. On-call responsibilities for SRE and DevOps roles in the UK attract between £3,000 and £8,000 per year in additional compensation when they are properly structured and paid. For engineers absorbing that availability without any additional pay, the arithmetic is clear: the gap between what they are owed and what they receive is not a minor inconvenience. It is a significant, recurring salary shortfall.
The traditional response to unpaid on-call is to accept it as part of the job. Engineers tell themselves that being responsive signals commitment, that pushing back will look like a lack of ownership, or that everyone else is doing the same so it must be normal. What this reasoning ignores is the compounding cost. Availability expectations rarely shrink once established. A culture where engineers are expected to respond to a Slack message at 10pm on a Wednesday will, in most organisations, gradually expand to cover weekends, bank holidays, and annual leave. The engineer who says nothing in year one typically finds themselves, by year three, with no realistic boundary left to defend. The career cost is not just financial: burnout rates in the UK tech industry have reached 82% of workers reporting they feel close to exhaustion, and always-on culture is one of the primary drivers.
The good news is that unpaid on-call is a solvable problem, and solving it does not require a confrontation. It requires preparation, language, and an understanding of where the leverage actually sits. This post covers two distinct audiences. For the engineer currently absorbing uncompensated availability, it provides a framework for assessing what you are owed, opening the conversation, and negotiating a formal arrangement. For the senior engineer or tech lead managing a team, it covers how to build a culture where on-call is properly defined, rotated, and compensated, and why doing so makes your team more stable and more retentive than any ping-pong table. The underlying principle is the same for both: availability is a professional service, and professional services have a price.
How the Expectation Creeps In
Unpaid on-call rarely arrives announced. It begins with a context message at 7pm that a colleague answers because it seemed quick. It continues when someone checks a monitoring dashboard over the weekend because there was a deployment on Friday and they wanted peace of mind. It solidifies when the on-call rota is introduced informally, with a week-by-week Slack pinned message rather than a policy document, and with no mention of what happens if something actually goes wrong at 2am.
By the time the expectation is fully embedded, it has the texture of culture rather than a specific requirement. No one formally asked engineers to be available all the time. The organisation simply arranged itself around the assumption that they would be, and stopped questioning whether that arrangement was appropriate. This distinction matters when it comes to addressing the situation, because there is rarely a single decision to push back against. There is instead a shared understanding to renegotiate, and that requires a different kind of conversation from filing a complaint about a specific policy.
The tech sector’s shift to remote and hybrid working has made this problem significantly worse. When work and home share the same physical space, and when communication tools are installed on personal devices, the signal that the working day has ended becomes difficult to transmit and even harder to receive. A 2024 CIPD survey found that 70% of senior leaders observed “leavism” in their organisations: employees using annual leave to work or recover from overwork, rather than to rest. This is not a productivity story. It is a retention and sustainability story, and it has a direct cost for the engineer experiencing it.
What UK Law Actually Says
The Working Time Regulations 1998 are worth understanding, even if they will not resolve the problem on their own. Under the regulations, working time is defined by control and availability: if an employer requires a worker to be at their disposal, that time is working time. The more restrictions placed on what a worker can do during an on-call period, the more likely it is that the period counts as working time for statutory purposes.
In practical terms, this means that an engineer required to respond to incidents within, say, thirty minutes, and who therefore cannot travel freely or consume alcohol during an on-call shift, has a reasonable argument that their on-call time constitutes working time under the regulations. Working time must be counted towards the 48-hour weekly average limit, and workers are entitled to at least 11 consecutive hours of rest between working days. Disrupted nights do not reset this entitlement: if a call-out runs until 2am, the engineer is entitled to 11 hours before their next working day begins.
Labour’s proposed “right to switch off” would have provided additional protection, allowing workers to refuse out-of-hours contact without penalty. That proposal was shelved in March 2025 and does not appear in the Employment Rights Act 2025. The issue is likely to return in future legislation, but for now there is no statutory right to ignore a work message outside contracted hours. What engineers do have is the Working Time Regulations framework, and the ability to use it as context when opening a negotiation. Knowing that the law treats heavily restricted on-call as working time changes the character of that conversation.
What Fair On-Call Looks Like
Before negotiating anything, it helps to know what you are negotiating towards. Across the UK IT sector, properly compensated on-call arrangements typically follow one of three models.
The standby allowance model pays a flat weekly or monthly rate for being available, regardless of whether any incidents occur. Incomes Data Research found in 2024 that standby premiums across UK organisations range from around 38% of standard hourly pay on weekdays up to 96% at bank holidays and over the Christmas and Easter period. In annual terms, this translates to thousands of pounds for genuine on-call coverage, with some organisations paying the equivalent of 10% of annual salary for the standby element alone.
The call-out rate model pays the standby allowance at a modest level, but triggers a premium payment whenever the engineer is actually required to work. Premiums typically range from 1.5 times the standard hourly rate on weekdays to double time on Sundays and bank holidays, with some arrangements also providing time off in lieu. This model works well when incident rates are low and predictable.
The third model, common at mature engineering organisations with formal SRE functions, builds on-call into the role’s total compensation from the outset. The base salary is set higher to reflect the on-call expectation, with a defined rota, escalation paths, and a clear distinction between the engineer responsible for first response and the broader team. When on-call is structured this way, it tends to be taken seriously: there is a blameless postmortem process, a reliability target, and an expectation that engineers who are frequently disturbed will take recovery time.
The model you are most likely to encounter at a mid-sized UK organisation is none of the above. Instead, there is an implicit expectation that key engineers will be contactable, no formal rota, and no additional pay. The negotiation, then, is about moving from that informal state to something closer to one of the models described above.
For the Engineer: How to Open the Conversation
The most effective approach is to make the conversation factual rather than emotional. You are not complaining about being bothered; you are proposing a structure that works better for both parties. That framing matters because it keeps the conversation focused on outcomes.
Start by documenting your current on-call activity for four to six weeks before raising anything formally. Note the time of each contact, whether it required active work or just a response, how long you were engaged, and whether it interrupted sleep or personal time. This produces a concrete picture of what is actually being asked of you, and it avoids the conversation degenerating into an argument about whether the requirement is “really” that significant.
When you are ready to raise it, frame the conversation around two things: what you are currently providing, and what the market rate for that provision looks like. A DevOps engineer on £70,000 per year, providing genuine on-call coverage three weeks in every four, is delivering a service that should attract £3,000 to £8,000 in additional annual compensation based on UK market norms. You are not demanding a pay rise: you are asking for your existing contribution to be correctly classified and compensated.
The specific ask should be concrete. Request either a formal standby allowance, a call-out rate structure, or an increase in base salary that reflects the on-call expectation. If the organisation pushes back on immediate financial change, time off in lieu for any out-of-hours incident response is a reasonable interim position. What you want to avoid is an outcome that acknowledges the problem but resolves nothing: a vague assurance that “we’ll keep it in mind” or that “things will calm down soon” is not an agreement.
Senior engineers at the £90,000 to £130,000 level often find it easier to have this conversation because they carry more internal credibility and because the organisation has more to lose from their departure. Mid-level engineers at £60,000 to £90,000 can make the same argument, but may need to be more explicit about the retention dimension: framing the conversation around “I want to make sure this is sustainable long term” is both honest and strategically sound.
One practical step that many engineers overlook is reviewing their employment contract before the conversation. Many contracts specify contracted hours and have no mention of on-call or out-of-hours availability. If your employer has added a Teams or Slack notification to your phone and expects you to respond to it at 11pm, without any contractual basis for that expectation, you have a stronger position than you might realise. You are not refusing to do your job. You are asking for a job description that matches the actual job.
For the Tech Lead: Building a Team That Is Not Expected to Work for Free
If you manage a team of cloud engineers, the on-call question will reach you from two directions simultaneously. From above, you will face pressure to maintain availability without expanding headcount or cost. From below, you will hear the attrition risk of engineers who are burning out or quietly interviewing for roles at organisations that do things differently.
The most effective thing a tech lead can do is to make the implicit explicit. Define, in writing, what on-call means for your team. Which services are covered, what the response expectation is, how the rota is structured, what constitutes an incident requiring out-of-hours response versus something that can wait until morning, and what the engineer on call receives in recognition of their availability. This does not need to be a formal HR document initially: a team agreement, shared in a space everyone can access, is sufficient to establish a baseline.
Rotation matters more than most leads acknowledge. A single engineer who is perpetually the de facto on-call resource, because they know the systems best or are the most likely to respond, is a single point of failure both technically and from a retention perspective. Distributing on-call across a team of four or five engineers, with proper handover documentation and a clear escalation path, reduces the individual burden significantly. The engineers who know the systems best should be available as an escalation, not as a first responder to every alert.
The business case for compensating on-call properly is not complicated. An engineer on £80,000 who leaves because they have been absorbing uncompensated availability for two years will cost the organisation somewhere between £16,000 and £24,000 to replace, before accounting for onboarding time and knowledge transfer. Paying a standby allowance of £4,000 per year is a clear piece of retention arithmetic. The difficulty is that recruitment costs sit on a different budget line from operational headcount costs, which means the saving is invisible to the person who makes the on-call decision. Making that calculation explicit when you are making the case to your own management is often the most persuasive thing you can do.
Alert quality is also within your control as a lead, and reducing alert noise is one of the highest-leverage improvements you can make to an on-call culture. If engineers are being paged for events that do not require immediate human intervention, or for alerts that fire repeatedly without a clear resolution path, the on-call burden grows without any corresponding increase in value. Investing time in tuning alerting thresholds, building runbooks for the most common incidents, and establishing a clear criterion for what constitutes a genuine out-of-hours response will make the on-call arrangement far more tolerable and far easier to compensate fairly. If a shift is routinely quiet, the standby allowance feels reasonable. If it is routinely chaotic, it will never feel like enough.
The conversation with your own management about formalising on-call compensation is worth having proactively rather than reactively. Engineers who are burning out or leaving rarely announce the specific reason clearly, which means the connection between uncompensated on-call and attrition is often invisible to senior leadership. Presenting the data first, including the frequency and timing of out-of-hours incidents, the number of engineers rotating through on-call, and the market rate for comparable availability in the UK, is a far stronger position than responding to a resignation.
When to Walk
Not every organisation will respond to a well-structured conversation about on-call compensation by improving its arrangements. Some will acknowledge the concern and do nothing. Others will respond defensively, treating the conversation as a sign of insufficient commitment. A small number will reframe the ask in terms that make it seem unreasonable: “everyone here is expected to go above and beyond” is a common formulation that is worth recognising as a negotiating tactic rather than a statement of fact.
The signals that an organisation is unlikely to change are worth paying attention to. If the conversation is repeatedly deferred, if the response is to describe the situation as temporary without providing any timeline or trigger for change, or if other engineers who have raised the same concern have been quietly sidelined, the structural incentives are working against you. These are not personal failures: they are characteristics of the organisation.
For engineers at the senior and staff level, the market for cloud talent in the UK remains strong. Cloud engineers with production experience earn between £90,000 and £130,000 at senior level, and Staff and Principal roles regularly reach £130,000 to £180,000. The organisations competing for that talent include many with mature on-call structures, formal SRE functions, and explicit compensation for availability. A move to one of those organisations will almost certainly pay more in total compensation than staying somewhere with an unstructured and uncompensated on-call culture, even before accounting for the value of protected personal time.
The post on this site covering the career cost of burnout is worth reading alongside this one: the financial case for protecting your sustainability is as strong as any argument for a salary negotiation. A career cut short by exhaustion is the most expensive outcome of all.
The Career Case for Getting This Right
There is a longer game here that is worth naming. Engineers who successfully negotiate their on-call terms are demonstrating a skill that becomes more valuable as careers progress: the ability to represent the commercial value of their work clearly and without apology. This is precisely the capability that separates staff-level contributors from senior ones. Senior engineers solve technical problems. Staff engineers understand the value of solving those problems, and can communicate that value to people who do not share their technical context.
Negotiating your on-call arrangement is a version of that skill, applied to your own situation. You are articulating what you provide, what it is worth on the open market, and what a sustainable and fair arrangement looks like. That is not a distraction from technical work. It is an early practice of the exact career capability that the highest-paid engineers in the UK market deploy regularly.
The engineers who are most effective at this do two things well. They keep records: of incidents, of on-call hours, of the value of the systems they support. And they invest time in understanding how their organisation makes financial decisions, so they can frame requests in terms the business responds to. Neither requires seniority. Both require intentionality.
Your time outside contracted hours has a market value. The first step to receiving it is deciding to ask.
Next Steps
This week: audit your current on-call activity. If you have not been keeping records, start now. Note each out-of-hours contact, whether it required active work, how long it took, and at what time it occurred. Four weeks of this data transforms a vague concern into a documented case.
This month: check your employment contract. Look specifically for any mention of on-call, standby, or out-of-hours availability expectations. If there is none, note that. If there is, read it carefully.
Within three months: bring the conversation to your line manager or, if you lead a team, to your organisation’s management. Use the market rate data from this post, your documented activity log, and a concrete proposal for what a fair arrangement looks like. A specific ask is far more likely to produce a result than a general expression of concern.
If you are a tech lead who has not yet formalised your team’s on-call arrangement, schedule time in the next two weeks to draft a basic team agreement. Define what is covered, what the rotation looks like, and what the engineer on call receives. It does not need to be perfect. It needs to exist.
Useful Links
- Acas: Being On Call
- DavidsonMorris: On-Call Work Rules UK 2026
- Incomes Data Research: Standby and Call-Out Pay Practices 2024
- Lawdit: The Employment Rights Act 2025
- Mental Health UK: Burnout Report 2025
- SavingTool: DevOps Engineer Pay UK 2025/26
- Brightmine: Right to Disconnect: What Can the UK Learn?
- Hays Tech Salary Guide 2025
- Cloud and Clear: Cloud Learning Fatigue
- Cloud and Clear: The Sabbatical Strategy
