Your Server Still Thinks It's a Laptop

I came home, opened my laptop, and the machine that runs my models was gone. Not slow — gone. It didn't answer on its name, it didn't answer over the VPN, it didn't answer at all.

Out of frustration I logged in directly over the local network. It answered instantly — and every other path started working again at the same moment, as though nothing had been wrong.

That machine is an M3 Ultra Mac Studio in my Dubai office. By any definition it's a server. Nothing about its configuration knew that: the idle-sleep timer was set to one minute — the factory default is ten — and it had slept and woken 24 times in the previous six hours.

That day I chased three separate failures on the same machine: a flaky connection, an unreliable one, a slow one. All three looked like a network problem. None of them was.

The machine wasn't down. It was asleep.

Laptops are supposed to sleep. Sleeping is the correct default when the thing is on your lap running off a battery. On a machine that has to answer at three in the morning, a one-minute idle timer is a scheduled outage.

What made it confusing is that the operating system has a wake mechanism for exactly this: another device on the network wakes the sleeping machine when a connection arrives. It works for ordinary connections — which is why logging in locally woke it. It does not wake it for VPN traffic, which is the only way I reach the machine from outside.

The failure was intermittent, route-dependent, and healed itself the moment you touched the machine from inside the building. A near-perfect disguise — and the fix was a settings change, not an architecture change: never sleep on mains power, disks never spin down, wake-on-LAN on.

The lesson for a business: a machine that has to answer while nobody is watching needs power settings written for a server, not the ones a manufacturer tuned for battery life in a bag.

Redundancy you can't control is just ambiguity

The same machine was connected two ways at once — Wi-Fi and Ethernet, both live, both on the same network. On paper that reads like redundancy. It wasn't. I'd connect over one path and the other went silent; connect over the second and the first went quiet instead. Two working paths, only ever one answering, and which one kept changing.

The machine had no consistent rule for which way to reply. A request arrived on one path and the answer left on the other; the far end, tracking the conversation it had started, didn't recognise the reply and threw it away. Nothing was broken — both paths were up the whole time. The machine just couldn't be relied on to answer the way it was asked.

Turning Wi-Fi off completely — one way in, one way out — made it stop.

The lesson for a business: a second path only helps if something deliberately decides when to use it. Two paths and no referee is worse than one — you've doubled the ways to be half-reachable, the hardest state there is to diagnose.

The 15-second network problem was never the network

The third failure is the one that would have cost real money. A request I sent from off-site took about 15 seconds to come back. The obvious suspect was the VPN link, and acting on that suspicion meant redesigning how I reach the machine.

Instead I ran the identical request on the machine itself, with no network involved at all. Warm, it came back in 1.0 seconds. On a partial cache miss, 4.1 seconds. When it landed behind work already in progress, 139 seconds.

139 seconds, with the network removed entirely. The delay was never in the transport — it was the model server queueing requests and recomputing work it should have had ready. Round trip to the nearest relay is about 17 milliseconds: under a tenth of a percent of the gap I was trying to explain. I was one decision from re-engineering the only component performing flawlessly.

This generalises well beyond servers. Before you spend money replacing the component you suspect, reproduce the symptom with that component out of the picture. If it survives, your suspect is innocent. It's how companies end up changing internet providers to fix a database problem.

All three arrived wearing the same costume

Three genuinely different faults — a power setting, a routing ambiguity, a server-side queue — presented identically. Intermittent. Route-dependent. Self-healing the moment you prodded it. Looked like the network, every time.

That resemblance is the expensive part, not the downtime. Each could have been "solved" by buying something — a better router, a second line, a different VPN — a permanent monthly cost defending against a checkbox. None would have shown up on a status dashboard either: the machine was up, the processes were running, and asked whether it was healthy it would have said yes.

An intermittent failure is not a milder version of a permanent one. It's a more expensive category: it survives your first three fixes and trains your team that the system is "just flaky".

Audit the defaults before you audit the architecture

If something in your company depends on a machine staying reachable — under a desk, in a cupboard, in a rack you inherited — check three things this week.

• Can it go to sleep? Mine was set to one minute; ten is what it shipped with. Neither is a server setting — the server setting is never, on mains power.
• Does it have more than one live way onto the network? If it does, and nobody deliberately chose which one answers, switch one off.
• Does its wake mechanism cover the way you actually connect? Mine woke for ordinary connections and not for the VPN — the only way in from outside.

None of these is an engineering project. All three are settings — and all three were wrong by default, because the defaults were written for a device that spends its life closed in a bag.

The bottom line

None of this was an AI problem, and none of it was a network problem. It was three consumer defaults on a machine quietly promoted to infrastructure without anyone updating its settings to match. The fixes took minutes each. Finding them took a day, because all three were in costume.

For the engineers

Idle sleep was one minute against a factory default of ten; the host had slept and woken 24 times in six hours. The OS sleep proxy wakes a sleeping host for ordinary inbound TCP connection attempts — which is why an SSH login from the LAN always worked — but not for WireGuard-based VPN traffic. So while asleep the VPN path is dead; a local login wakes the host, and the VPN path then appears to recover on its own. Fix: idle sleep and disk sleep off on AC, wake-on-LAN on, and never rely on the sleep proxy for VPN traffic.

Dual-homing: two interfaces live on the same subnet. Outbound interface selection follows OS service-order priority, not the interface the request arrived on. The reply leaves on the wrong interface, the peer's stateful firewall drops it as unsolicited, and whichever path didn't send the last reply looks dead.

Latency triage: reproduce over loopback. Identical request, zero network — 1.0s warm with 13 of 14 prompt tokens cached, 4.1s on a partial cache miss, 139s when queued behind in-flight work with 0 of 14 cached. Nearest-relay round trip was about 17ms. Reproducing that order of magnitude with no network exonerates the transport; the search moves to cache-hit rate and concurrency.

Two weeks after I fixed these, a scheduled reboot exposed a different set of inherited defaults entirely — The Reboot That Locked Itself Behind a Login Screen is what happens when a server keeps a laptop's security settings too. And this is why I wrote Automation That Survives Contact With Reality: the machine has to keep answering when nobody is watching, not just when you are.

If your business depends on a machine staying reachable when nobody's in the office — a server under a desk, a box in a branch, whatever your automation actually runs on — and it keeps going "flaky" in ways nobody can reproduce, that's a good use of an on-site day: I'll go through its power, network and startup settings like a pre-flight checklist and leave you with a machine that answers when it's asked. Book a consulting day or send me an inquiry first if you'd rather talk before booking.