At about 6.30am on Monday 12 October 2026, every website on my server stopped responding: my radio station’s site, my blogs, this one, all of them. Ping and SSH timed out. My hosting control panel said the server was “On” the whole time. It was back at 7.07am, about 35 minutes later, after one command typed into a remote console. Here’s what happened, and what I’d check if you run your sites the same way.
“On” doesn’t mean up
My VPS is with Ionos, and the Cloud Panel’s status is just whether the virtual machine has power. A server can be powered, stalled and off the network, and the panel will still show a reassuring green “On”. If your host’s panel is the only thing you check, you’ll lose time. The tool that got me in was the Remote Console, which is a keyboard and screen on the server through the browser, and works when the network doesn’t.
What actually went wrong
The console showed two things. The out-of-memory killer had ended MariaDB, the database behind most of the sites, and the server’s network interface had no IP address. It had asked for one at 6.41am, got no answer and given up. Running netplan apply fetched the address again and everything came straight back. No reboot, and the database had already restarted itself cleanly.
The memory story is the interesting part. When the kernel logged its snapshot, the server had:
- 112 cron processes (a healthy box has a handful)
- 45 PHP-FPM workers
- 21 idle Claude Code sessions I’d left open since late September, about 300MB each
- no swap at all
My best guess, and it’s a guess, is that a network share to my backup storage hung, every job that touched it hung too, and the cron jobs kept firing on schedule and piling up behind each other. Without swap, the server ran out of memory and stalled for about 20 minutes, and lost its network address along the way. I’ve asked Ionos to check their side too.
What it costs a site owner
35 minutes at 6.30am on a Monday isn’t a disaster. Traffic is low, and a short outage like this shouldn’t do lasting harm in search, because crawlers come back. The real risks are the ones you don’t see:
- Everything was on one box. Every site I run went down at once, including the radio station. If you host clients’ or several brands’ sites on one VPS, one bad morning hits all of them.
- The warning signs were there and nobody was looking. My uptime monitor only tells me when a site is already down. Nothing was watching memory, swap or the number of running processes, which would have shown the pile-up building.
- The disk was quietly filling up. While I was in there I found the server at 87% full, with about 75GB of MP3s in one WordPress uploads folder. That’s the next outage waiting to happen if I leave it.
- The fix needed a person. The network didn’t recover by itself. If I’d been asleep or abroad, those 35 minutes could have been hours.
What I changed
- Added 4GB of swap. Running short of memory now means slow pages, not a dead server.
- Stopped cron jobs stacking up. Every frequent job now runs through
flock, so a new copy won’t start while the last one is still going, andtimeout, so a stuck one gets killed. I wrote up the PHP side of this on Codebusters: how to stop a PHP cron job running twice at once. - Made the network share fail safely. If the backup storage stops answering, scripts now get an error after a short wait instead of hanging forever.
- Protected the database. MariaDB is now near the bottom of the list when the server picks something to kill, and the AI sessions have a memory cap.
- Raised a ticket with the host about why the network didn’t come back on its own.
What I’d check on your server
- Run
free -m. If the Swap line says 0, add some. - Look at your crontab. Any job running every minute or every five minutes should have
flockandtimeoutin front of it. - Run
df -h. Anything over 85% needs a plan now, not when it hits 100%. - Find out how you get into your server when SSH doesn’t work, before you need to. Write the steps somewhere that isn’t on the server.
- Monitor memory and disk, not just whether the homepage loads.
- Close the things you’ve left running. I’m talking to myself here.
That last point is the one that stings. The tool I’d normally use to fix the server was, quite possibly, part of what knocked it over.
This is the latest in a short series about my own sites going wrong. The others cover a weekly outage caused by my own Ahrefs Site Audit, pages Google crawled and didn’t index and sponsored posts and site reputation abuse.