A local record of "the last deploy" goes stale the moment a second machine deploys anything. On a multi-machine estate, the platform’s own history is the only version worth trusting.
I run my deployment tooling from two machines, and for a while each of them kept its own idea of what had last been deployed: a local file, updated on every successful run, recording the version and the timestamp so a rollback command would have something to roll back to without me having to remember. It worked cleanly for months, because for months I only ever deployed from one of the two machines. The day I deployed the same service from the other one, that local record became a lie the instant it was written, and neither machine had any way to know it.
The failure mode is specific and easy to miss until it bites. Machine A deploys version twelve and writes "last deploy: 12" to its local state. An hour later, machine B — which still believes the last deploy was version eleven, because it has no idea machine A did anything — runs a rollback, intending to undo a bad change of its own, and rolls back to what it thinks is the last known good version. It is rolling back relative to a fact that stopped being true the moment machine A deployed. Nothing in that sequence throws an error. The rollback command runs, reports success, and quietly moves the service to the wrong place, because the source of truth it consulted was a cache of a fact that no longer holds.
The fix is not to synchronise the two machines’ local records more carefully. Any synchronisation scheme is still a copy, and a copy can always be stale relative to the platform doing the actual deploying. The fix is to stop keeping a local record of deploy state at all, and to ask the platform instead. Every deploy target I have used — a container platform, a serverless runtime, a CDN edge network — already keeps its own authoritative history of what was deployed, when, and by what identifier. That history is updated by the one thing that can actually change deploy state, which is the platform itself doing the deploying. It cannot go stale relative to itself.
This changes the shape of a rollback command in a way that feels slightly less convenient at first. Instead of a bare "roll back to the last one", which relies on local memory of what "the last one" was, the command has to ask the platform for its deployment history and either show me a short list to pick from or take an explicit deployment identifier as an argument. That extra step — naming the exact deployment rather than trusting an implicit "previous" — is the whole fix. It costs one more look at a list. It buys certainty that the rollback target is the one the platform actually remembers deploying, not the one some machine’s local file guessed it was.
The general shape of the mistake is bigger than deploy tooling. Any state that more than one machine can change is wrong the moment it is cached locally and a second machine changes it without the first one hearing about it. I had built the same bug once before, in a different tool, tracking "the last processed item" in a local file while two machines both pulled from the same queue. The fix was the same both times: stop keeping your own ledger of a fact that belongs to a system already keeping one, and go ask that system instead. A local cache of shared state is a bet that nothing else touches that state between reads, and on an estate with more than one machine, that bet loses eventually.