What protects you: preflight and automatic rollback

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 a reversible configuration change

When the operation changes configuration that can be restored, the backup is taken on the device itself before the first command. A backup cannot roll back a RouterOS or bootloader version.

4 — Automatic rollback (the dead-man)

For reversible configuration changes, 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, package activation and device-mode activation have no safe remote inverse. Their safety lives in the operation-specific preflight and return verification — 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). A refusal here means the system found a specific risk before touching the device.

The same applies to permanent purges of vouchers or the hotspot: what is deleted cannot be recovered. Read the screen carefully before confirming.