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.
Published 24 August 2026
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. 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 does precisely what you tell it, including the destructive thing, and it does 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, verifies which host and path it is pointed at, and requires 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 pre-flight guard has produced zero repeat incidents since it shipped: the failure mode is blocked by tooling rather than discipline, and the same mistake cannot be made the same way again.
What we'd do differently
Write the guard before you need it. Building it cost an hour; learning we needed it cost 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 the incident honestly and made it structurally impossible to repeat.