Clockflux

When the patch can't wait: doing overtime, then taking it back

Mental healthHours & pay6 min readBy

On Wednesday 21 October, a lot of people who look after servers had their evening planned for them. PHP and Node.js both published security fixes that day, and both included flaws that could let an attacker run code on a server from the outside. If your job is keeping websites or APIs running, that was not a day to log off at five.

Most of our posts so far have been about protecting your evenings and the rest between working days. This one is about the times when staying late really is the right call, and about what comes after.

What happened on 21 October

PHP. The PHP project published two advisories on GitHub, CVE-2026-109618 and CVE-2026-109619, both rated critical with a score of 9.2. The first comes from the way PHP handles running out of memory in the middle of a request. The second lets state from one finished request linger in freed memory, where the next request on the same worker can pick it up. In both cases the advisories say an attacker could end up running code as the web server's user, without logging in. The fixes are in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

Google Cloud's write-up puts the scale in one line: every version of PHP from 5.4 through 8.5.11 is affected, and versions 8.1 and older, which have reached end of life, aren't getting fixes. It also points out that upgrading the package isn't enough on its own. The PHP workers already running keep the old code in memory until you restart them.

Node.js. The same day, Node.js shipped security releases fixing ten vulnerabilities, four of them rated high. The most serious, CVE-2026-111497, is in the Brotli decoder bundled with Node.js. Malformed compressed data can make it write past the end of an internal buffer, and an attacker who can get an application to decompress their data with node:zlib could crash it, read its memory or run code. It affects Node.js 22, 24 and 26, and the fixed versions are 22.23.4, 24.22.1 and 26.12.1.

So on one Wednesday, a large share of the web's servers needed patching, testing and restarting, many of them as soon as possible. Somebody had to do it, and for a lot of people that meant a long day, a late night or both.

Some overtime is worth doing

We spend a lot of time on this blog warning about long hours, so it's fair to say plainly: a day like that is a good reason to work late. A known hole that lets strangers run code on your servers doesn't wait politely until Monday. Patching it quickly protects your users, your colleagues and quite possibly your own weekend.

What makes it reasonable overtime is that it's rare and it's for something real. A security release is an event with a start and an end. You know why you're staying, you know roughly when you'll be done, and you can point at the reason afterwards.

The trouble starts when the event is over but the hours aren't. The patched servers are running, and the next morning there's a review to write, a backlog that waited a day, and a few systems somebody forgot. Then a third flaw gets announced, or the next release comes along. A late night turns into a late week, and the late week becomes the normal one without anybody deciding it should.

What the long stretch costs

We've covered the evidence in earlier posts, so here's the short version. Long weeks go with higher burnout and with work getting in the way of home life, as the Norwegian study in where work ends found. Short gaps between working days go with shorter sleep and more sick leave, which we looked at in the 11 hours between working days.

There's a practical side as well. Patching under pressure is careful work: reading advisories, checking versions, remembering to restart the workers. It's the kind of job tired people get wrong, and a missed restart leaves a server looking patched while it's still running the old code.

How to know it's time to take the hours back

  1. Name the event. Write down why you're working late and what "done" looks like: "PHP patched and workers restarted on all servers". When that's true, the overtime ends.
  2. Record the hours, even the ones nobody asked for. Check in when you start and out when you stop, including the half hour on the sofa checking the logs. You can't take back time you never wrote down.
  3. Take something back within a week or two. A later start the day after, an early finish on Friday, or a whole day if the night was long. The longer you wait, the easier it is to forget you're owed it.
  4. Protect the next night's rest. If you finished at midnight, don't be at your desk at 8. Eleven hours off is the legal minimum in the EU and the UK for a reason.
  5. Watch the balance, not the day. One late night is fine. If your overtime keeps climbing for a month after the incident is closed, the incident isn't what's keeping you late any more.
  6. Make the next one easier. Write down what slowed you down: a server nobody knew was there, an old version that couldn't be upgraded. That list is how the next security release becomes an evening instead of a weekend.

If your employer gives time off in lieu, the guide to TOIL and flexitime explains how those hours are usually earned and taken, and why it's worth having the rules in writing.

Where Clockflux fits in

The Health view in Clockflux keeps a running overtime balance: each completed week's hours minus its target, added up. A chart shows how that balance has moved over time, with a breakdown of your hours against your target for each recent week.

If you spent this Wednesday night patching, this week will show up on that chart as a jump once it's finished. What matters is what the line does next. If it comes back down over the following weeks because you started later and left earlier, you took the time back. If it keeps climbing, that's the signal to stop and take a day.

To take a day back, leave it as an ordinary workday and don't check in. The day's target comes off your balance and the chart drops with it. Don't mark it as a day off in the calendar, because that takes the day out of your target instead and leaves the balance where it was. The status at the top of the Health view helps too: a lighter stretch that spends overtime you've built up still counts as on track.

On the free plan the Health stats cover the current year, and Clockflux Pro covers your full history. For a single week, the overtime calculator adds up your hours against your target.

For what it's worth, the Clockflux API is written in Go and our sites are served as static files, so we watched this one from the side.

If the pressure of being on call, or of always being the one who fixes things, is affecting your sleep or your health, please talk to someone: your doctor, a mental health professional or an employee assistance programme if your employer offers one. Tracking your hours can show you a pattern. It is not a substitute for support.