What protects you: preflight and automatic rollback
Published: 2026-08-12
Why some operations are refused, and how a router restores itself when a change cannot be proven safe.
Everything in the Operations Center rests on one rule: a remote router is never gambled with. Here is what actually happens around every operation.
1 — A preflight check before every run
Before any command is sent, each router is checked on its own: does it answer? Is it genuinely the expected device (its serial is verified)? Is the tunnel healthy? Is there enough storage? Is its clock right? Then operation-specific checks.
A refusal is not a fault — it is the protection working. The router is left exactly as it was, and you get a sentence explaining why and what to do about it.
A preflight result is valid for 15 minutes; after that it is re-run, because a decision built on stale state is not a safe decision.
2 — Typed confirmation
Guarded operations ask you to type a confirmation code shown on screen, so a dangerous change is a deliberate decision rather than a stray click.
3 — A backup before the change
Taken on the device itself, before the first command.
4 — Automatic rollback (the dead-man)
Immediately before the change, a timer is installed on the router that is entirely independent of us. If the change succeeds and we prove the device is healthy, the timer is removed. If the link drops or verification fails, the timer runs from inside the router and restores the previous configuration — without us needing to reach it.
This is the essential point: the protection does not depend on our connection surviving. It exists precisely for when it does not.
5 — Verification over a fresh connection
An operation is not called successful because commands were accepted. A new connection is opened to the router, the state is read back, and its identity re-confirmed. Failure to prove it means rollback, never a silent success.
6 — One router at a time
Guarded operations run in sequence, so a single mistake can never take down two devices at once.
Operations with no rollback
RouterOS upgrades, bootloader upgrades, reboots and package installs have no inverse. Their entire safety lives in the preflight — which is why their checks are stricter, and why they refuse for reasons that can look harsh (a lagging bootloader, insufficient storage, an unset clock, a recent power cut). Every one of those refusals prevented a real failure.
The same applies to permanent purges of vouchers or the hotspot: what is deleted cannot be recovered. Read the screen carefully before confirming.