Photon, a company that develops a framework for connecting software agents to multiple messaging platforms, found a bug in macOS that causes TCP networking to fail sometime after 49 days of uptime. It sounds dire:
Every Mac has a hidden expiration date. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple’s XNU kernel freezes the internal TCP timestamp clock. Once frozen, TIME_WAIT connections never expire, ephemeral ports slowly exhaust, and eventually no new TCP connections can be established at all. ICMP (ping) keeps working. Everything else dies. The only fix most people know is a reboot. We discovered this bug on our iMessage service monitoring fleet, reproduced it live on two machines, and traced the root cause to a single comparison in the XNU kernel source.
I don’t recommend reading Photon’s exhaustively detailed post (which reads like it may have been generated by an AI) unless you’re extremely familiar with TCP networking code. Nevertheless, with some additional background from a Hacker News discussion, it seems that most people don’t need to worry about it because:
Most consumer Macs are rebooted for security updates well before reaching 49 days of uptime. Or at least they should be! Keep installing those updates.
Although Apple doesn’t guarantee updates within 49 days, the bug doesn’t cause instant failure at the 49-day mark. It merely prevents new TCP connections from being established. On a lightly used Mac, the resulting port exhaustion could take considerably longer to become noticeable.
If the Mac sleeps, the time could be significantly longer than 49 days.
It appears that the bug originated in the XNU kernel in macOS 26, so previous versions shouldn’t be affected. I suspect that many people with Mac media servers and other seldom-restarted Macs often aren’t running the latest version of macOS.
Assuming that Photon has reported this bug to Apple (I couldn’t find any discussion of it in the Apple Developer Forums), it should be straightforward to fix in the upcoming macOS 26.5.
That said, the bug does appear to be real, so if you have a macOS 26-based server that doesn’t sleep, it might be worth watching it—or restarting proactively if it’s remote—when its uptime reaches 49 days.
To see how long your Mac has been running since the last restart, open Terminal and enter the command uptime. I’m at 15 days on my main Mac. Anyone out there running macOS 26 with an uptime over 49 days?
My current uptime is 14 days since that’s how long it’s been since 26.4 was publicly released. There was an 8 and a half week gap between the release of 26.2 and 26.3, but the Christmas holidays fell in-between and I probably shut my Mac down while I was visiting family for the holidays. Aside from that the 26 releases have been less than 7 weeks apart so I probably never went 7 weeks straight without restarting 26. Maybe this summer when the releases slow down leading up to 27 that will happen, but I expect this bug will have been fixed by then.
I want to say that I’ve had more than 7 weeks uptime in the past - I used to run a Mini as a server and prior to that I had a Mac Pro that ran Folding@Home and so never slept - but it’s not something I’ve ever paid attention to.
According to the Michael Tsai blog, this bug may have existed since macOS 10.15 (Catalina), but he (and I) have had Macs from that era with very long uptimes, much longer than 49 days, without seeing this problem.
On the other hand, I have occasionally seen macOS get into a weird state where it constantly asks for my iCloud password for routine things (iMessage, Calendar, Music, etc.) and doesn’t stop asking (with or without a password) until I reboot. So maybe that is/was a symptom of this bug.
I use my M4 Mac Mini about 95% of the time, and when I am done, I shut it down. For the remaining 5% that I use my M3 MacBook Air, I also shut it down when I am done. Problem solved!
I have noticed that when I leave the mini and my MacBookAir running for long times they eventually crash and require rebooting for no obvious reason, which the 49-day bug explains. No real problem for me, but I could imagine it might be a significant issue if you are running a Mac to manage something that needs to be always on all the time.
This bug has come and gone in various operating systems for years and years. 30+ years ago, I encountered it on both Windows and VAX/VMS where it was the uptime register overflowing. Windows counted up time in milliseconds which overflowed at 49+ days but back then, it was nearly impossible for nothing to go wrong in Windows that required a reboot so that you could keep a Windows system up for 49 days. VAX/VMS, OTOH, measured uptime in tens of milliseconds so you had 497 days before it bit you. Again, almost impossible as there would almost certainly be an operating system update in that time requiring a reboot but I did manage to do it once on a system I administered (and due to another “feature”, you really wanted to do a normal shutdown in the first 132 days of the year - at least back then, system time was determined at boot by a combination of a hardware time-of-year (TOY) clock and an on-disk file that said what year the time-of-year clock was referencing. A normal shutdown updated the TOY clock and year file if it had moved into a new year; a crash or power outage did not so once the TOY clock overflowed, time at the next boot, if a normal shutdown was not done, would be incorrect).
I would think there has to be some “down time” available no matter what one does. And the turning off then on process only takes a few minutes.
I guess there are certain professions where a machine is required to be on all the time. But if it’s a desktop, the electricity could go out. Thus one would need a backup machine. If one relies on a laptop for this, its battery could easily run low, and if the electricity is gone, that would be bad. So maybe best to rely on a desktop for the primary machine, with a fully charged laptop as a backup. Then the shutting down and starting up again “exercise” for each machine becomes dooable.
I usually reboot my work laptop (Windows 11) once a week when signing off on Friday evenings. (I just log out the rest of the week).
For a server, maybe not. But these days, it’s far more important to have service uptime, not necessarily uptime for one server. If you have redundant servers, then you can reboot/upgrade them individually, so your service remains up the entire time. And if your service isn’t important enough to need redundancy, then you can probably afford the occasional scheduled reboot.
