Operations & safety

The incident and the guard rail

We destroyed a WordPress install over SSH. Here's the post-mortem, and the script that makes it impossible to repeat.

0repeat incidents since the guard shipped

Context

During a build, a command run over SSH wiped a WordPress installation. It was our own environment and our own mistake, and no client data was involved, but it was exactly the class of error that ends a client relationship if it happens on their infrastructure.

The constraint

Deploying over SSH means operating without the safety net a managed platform gives you. The tooling will do precisely what you tell it, including the destructive thing, and it will do it instantly.

What we built

Wrote a full post-mortem while it was fresh: what was run, what was assumed, and the exact point where the assumption broke.
Shipped an automated pre-flight script that runs before any destructive operation, verifying which host and path it is pointed at and requiring explicit confirmation.
Made the guard part of the deploy path rather than a rule to remember, because rules that depend on memory fail under time pressure.

The result

The failure mode is now blocked by tooling rather than discipline. The same mistake cannot be made the same way again.

What we'd do differently

We'd have written the guard before we needed it. The cost of building it was an hour; the cost of learning we needed it was a rebuild.

Why this matters for you: We publish this one deliberately. Every agency has incidents. Most just don't tell you. What's worth judging is whether they diagnosed it honestly and made it structurally impossible to repeat.