All posts

How I took down my own website

3 min read

AI agents work on this website. I write down what needs doing, they do it, and I check their work afterwards. It saves me a lot of time, and most of the time it works surprisingly well.

This morning, one of them was supposed to tidy up after itself — to shut down the test copy of the site it had been running while it worked. It tidied up. Unfortunately, it shut down the live one too, the one you’re reading this on right now.

Why nobody noticed right away

The best part is how long it took before anyone noticed.

The test and live versions of the site run on the same server, and as far as the computer is concerned, they have exactly the same name. So the agent sent the command “shut down whatever’s called this” and hit both. But the live version runs in Docker, and Docker has a watchdog that automatically starts a stopped application back up.

So: the agent shut the site down, Docker immediately started it again, the agent looked, saw that the application was still running, and concluded the command hadn’t worked. So it sent it again. Then two more agents did the same — including the one that had been handing out the work. Meanwhile the site went down seven times and came back up seven times, each outage lasting a few seconds — and each of them was puzzled about why it couldn’t shut down something it had just shut down.

And the mistake wasn’t the agents’. It was in the environment I’d set up for them. The brief said only “stop the server.” Shutting down a process by its name is a perfectly reasonable thing to do on a computer where nothing live with the same name is running alongside. On this one, something live was running under the same name — and nowhere did it say that processes therefore must never be stopped by name. It didn’t occur to me to put it in the rules they all read.

Why I’m writing about it

I could have quietly fixed it. Nobody’s work was interrupted, no visitor noticed, the damage was zero.

But this is exactly the kind of thing a prospective client should know up front. Not that nothing ever goes wrong for me — that would be a lie, and they know it. But that when something does go wrong, they’ll hear it from me, not from their own people. And that they stand a chance of undoing it before it turns into a problem.

That’s why the site has two things that have nothing to do with how it looks. It reports on its own whether it’s healthy, so nobody finds out its state by happening to look at it. And every version can be rolled back within a minute.

None of that prevents mistakes. But it shortens the time between “something’s gone wrong” and “it’s fine again” — and that’s the only number anyone really cares about at a moment like that.

More posts