At 4:41 in the morning I moved the WAN uplink on my gateway off a 10-gigabit port and down to port 1, purely so I could have the fast ports back for something else. The public address didn't change. Within seconds every tunnelled hostname I own — sonarr, radarr, nas, photo — was serving Cloudflare error 1033, which is the edge telling you it can't reach your tunnel. I typed "solve this" and went looking. Five minutes later it was closed, and it had already been fixed for four of those five minutes.
Three minutes of real outage
The cloudflared container had been up for seven hours and never restarted, and its logs told the whole story in four lines. All four edge connections dropped between 04:37:36 and 04:39:01 — the connector holds redundant sessions to more than one Cloudflare point of presence, in my case Perth and Melbourne — and at 04:40:13 it started dialling back out on its own. By the time I reported an outage it was showing four ready connections and 6,710 requests served.
The very first probe of the investigation, at 04:42, came back healthy: photo returned 200, radarr 302, nas 307, straight through the tunnel. Real outage, from the link bouncing to the sessions re-registering, was about three minutes. What I was still staring at was my own browser, holding onto the failed lookups and the 1033 page long after the thing behind them had recovered. A hard refresh would have ended the incident before it started. I restarted the container anyway, belt and braces rather than a fix.
The screen of zeroes
Then the best wrong turn of the day. To verify all eight hostnames end to end, the check resolved each one at a Cloudflare edge address instead of trusting DNS, and it tried to be clever about finding that address by resolving the apex domain. My apex doesn't point at the tunnel. It points at the static-site host where the portfolio lives. So all eight subdomains got forced there, and every endpoint came back HTTP 000. Eight of them, in a column.
For about a minute the fix looked like it had made everything worse. It hadn't. The test was pointing the entire lab at a web host that has never heard of any of it. Corrected to resolve each hostname at its own edge, all eight came back clean, zero 1033s.
The part worth writing down is the bit I only half understood before this. These tunnels are outbound-only: the connector dials out to Cloudflare on 443 and holds the sessions open, and nothing on the internet ever connects inward to me. Moving the WAN port needed no port forwards and no firewall rules. There was no configuration to break. The swap just bounced the link, and the sessions came back stale. I was offered a healthcheck-based auto-restart so it self-heals faster next time, and I said no. Three minutes doesn't justify another moving part.
A Linux box coaching a Windows PC through a disk wipe
Later that morning, a different kind of stuck: a 256 GB flash drive with three partitions on it that refused to format as exFAT, reporting itself as protected.
The first move was to identify the device rather than act on it, which is how we found out the drive wasn't there. lsblk on the server showed one NVMe system disk and nothing else, and the only USB device attached to the whole machine was a 2.5-gig LAN adapter. Then, from me: it's on my Windows PC. So the rest of this is a Linux server that physically cannot see the drive, coaching Windows' diskpart through a destructive operation by copy-paste relay.
What came back looked bad. A Kingston DataTraveler, and two leftover volumes marked unusable that added up to about four gigabytes. Four gigabytes on a drive claiming 256 is the textbook signature of a counterfeit: a small chip with firmware that lies about its capacity, so a format "succeeds", reports the full size, and then silently eats everything written past the real limit. DataTraveler is one of the most faked models on the market. That was an unpleasant thirty seconds. list disk settled it — disk 2, 231 GB, genuine. The four gigabytes were just junk partitions, already wiped by then.
Which is when the actual problem showed up, and it was much dumber. clean succeeded, create partition primary succeeded, and then format fs=exfat failed with "There is no volume selected." Wiping a disk drops diskpart's focus, so you have to select the partition you just made before you can format it. Fine. Except somewhere in there a format got going without the quick flag, which on 231 GB means watching a counter crawl, and cancelling it wedged Windows' Virtual Disk Service: "a concurrent second call is made on an object before the first is completed." The cancelled call was still sitting in there unfinished, refusing to let another one start. net stop vds answered with "the requested pause, continue, or stop is not valid for this service."
The honest advice at that point was to stop fighting it: reboot the PC, then format from File Explorer, which doesn't go through the same path. The record ends one minute later with no follow-up anywhere, so I'm not going to claim it worked. The drive is genuine, unlocked, wiped and carrying one primary partition, and as far as this journal knows it is still sitting there unformatted.
The thing I didn't notice
Somewhere around 6:20 that morning, in between the two, every access point in the house and all three of the little wall switches rebooted together. The core switch and the gateway stayed up. I only worked that out the following night from uptimes that had clustered, so treat the timing as derived rather than logged. A synchronised failure that hits the devices sharing power and skips the ones that don't is the shape of a power event, not a fault.
Two of the day's emergencies were over before I started solving them. The third was a flash drive I successfully identified, unlocked, wiped and partitioned, and then did not format.