How One Remote Reboot Cost Me Three Days of Work

I write software for a living, mostly small mobile games. Last week I was also setting up a Windows machine at a site I can only reach over the network. The site is a three-day trip away for me, so everything I do there happens through a remote session. On Saturday morning I was in the middle of that setup, around ten o'clock. One of the checks I had written down was simple: reboot the machine and confirm that the app comes back up on its own. It is a reasonable test. Anything that is supposed to run unattended has to survive a restart. The test went out. The machine went down and did not come back. What I had not checked The Windows on that machine does not live on its internal disk. It boots from an external drive that I had attached earlier. Before the reboot, I had not asked a basic question: if the machine restarts, what makes it boot from that drive again? I assumed it would. I had not worked out how that boot would be restored after a restart, and I could not check it from where I was sitting. So the reboot was a one-way door. If it worked, I would learn that the app survives a restart. If it did not, I would be locked out of a computer I could not touch. I told my partner what had happened. The reply was short and angry, and it was fair: do not reboot; I am three days away from getting there. What it cost Three days with the machine unreachable, until I could physically stand in front of it. Every remote step that came after the reboot in my plan, all of them waiting on a machine that was not answering. The reboot test itself was cheap. Losing the ability to run anything else was the expensive part. Where my judgment was wrong I treated "restart" as a harmless action because on my own desk it is. On my desk, if something goes wrong, I press a key during startup or plug in a monitor. On a remote machine, the same action has no undo. The question I should have asked takes under a minute: if this goes wrong, what is the way back, and can I walk it from here? If the answer is "someone has to go there", the action does not belong in a routine checklist. It belongs in a separate, deliberate step, with a person on site or with a second way into the machine, like a network power switch or a remote management port. What I am doing differently Three rules. I have not automated any of them yet; this is the plan: No reboot, shutdown or power action over the remote session unless someone is physically at the machine. Before any step that cannot be undone remotely, write down the way back in one line. If I cannot write the line, the step waits. The boot order gets checked on site, first thing, before anything else is installed. None of this is clever. It is the kind of rule that feels too obvious to write down until the day it costs you three days. A question for people who manage remote hardware If you operate machines you cannot walk up to, what is your cheapest "second way in"? A remote power switch only helps if the machine is set to power on by itself afterwards, and I do not know yet whether this one is.