Checking a fleet for RouterOS and firmware updates, and installing them without rebooting the switch that feeds everything else first.
The Upgrades page asks each selected device what it is running and what it could run. This is a live query against the routers, not a cached guess, so a check on a large fleet takes as long as the slowest device.
Checks run several devices at a time from a pool that refills as slots free up — one slow or unreachable device delays itself, not the batch behind it. The page shows the latest RouterOS releases separately, so you can see what is current even before checking anything.
A check reports two independent things: the RouterOS version and the routerboard firmware. They move separately, and a device can be current on one and behind on the other.
A version number does not say whether you want it. Click any of the version badges on the Upgrades page — or What's new on a device page that has an update pending — to read that version's RouterOS changelog without leaving mikr.
The entries are grouped by package, so a release with a few hundred lines reads as sections rather than a wall. Anything MikroTik marked with its own !) flag, and anything naming a CVE, is pulled to the top and highlighted. Everything else keeps the vendor's wording exactly.
The text is fetched from MikroTik when you ask for it, so a version MikroTik has not published — a build your device is running from the testing branch, for instance — will report that no changelog exists rather than showing a stale one.
| Action | What happens |
|---|---|
| Upgrade RouterOS | Downloads and installs the RouterOS package, then reboots to apply it, then verifies what came back up. |
| Upgrade firmware | Writes the routerboard firmware and reboots. Firmware is only applied on reboot, so this always costs a restart. |
| Full upgrade | RouterOS first; when that is done — or when the device turned out to be current already — it re-checks the firmware and upgrades it only if there is something to install. Two reboots at most, one if only one part was behind. |
| Reboot | Just a restart. The connection dropping is treated as success, because that is what a reboot looks like from outside. |
Full upgrade is the one to reach for. Doing RouterOS and firmware as two separate passes over the same fleet means two rounds of reboots for no benefit.
Those four are buttons on the Upgrades page, where you are acting on a selection of devices. On a single device's own page the same choice arrives differently: when a check finds an update, one Update button appears, and it opens a short dialog offering the full upgrade, RouterOS only, or firmware only — each stating what it installs and how many reboots to expect. That version's release notes open in the same dialog, so you can read them and choose without going anywhere. There is no second confirmation behind those buttons: the dialog is it.
Upgrading a whole site at once is rarely what you want: the moment a distribution switch reboots, everything behind it goes dark and its own upgrade never reports back. The queue exists for that. It runs one device at a time, in an order you control, and only one queue runs at a time across the whole installation.
Before starting, the queue can work out an order from the PoE topology of the devices you selected — which device powers which. Powered devices are handled before the device feeding them, so nothing is upgraded through a link that is about to disappear.
This uses what the devices report about their own PoE ports. It orders what it can see; it is not a substitute for knowing your own topology, and an uplink that carries no PoE is invisible to it.
Every step of an upgrade has a time limit — installing, writing firmware, rebooting, and each check against MikroTik's update server. A device that goes quiet is marked failed with the reason, and the queue moves on to the next one; it does not wait indefinitely, and it does not report a silent device as upgraded. The limits are generous, so a slow link is not mistaken for a failure. If a queue stalls regardless, starting a new one releases it. (v1.72.1+)
A running queue can be cancelled; the device currently being upgraded finishes first. A queue that was interrupted by the manager itself restarting is marked failed rather than silently resumed — a half-finished upgrade run is not something to continue blind.
An upgrade can be scheduled per device, so the reboot lands in a window you chose rather than in the middle of the working day. Schedules are listed and managed together, and can be cleared in bulk.
Scheduling does not change what an upgrade does — it changes when. Everything on this page still applies, including the fact that a firmware upgrade reboots.
Starting an upgrade returns immediately; the work continues in the background. Progress arrives over a live connection, phase by phase — checking, installing, rebooting, verifying.
Running upgrades stay visible from any page in the Active Tasks tray, and survive a page reload: closing the tab does not stop the run and does not lose its log. If nothing moves at all, the live connection is the first thing to suspect rather than the upgrade — see Troubleshooting.
A finished batch can also fire a webhook, so a fleet-wide run can report its own summary without anyone watching the page.
Two refusals are deliberate and worth recognising:
Site scope applies on top of the role: an upgrade only ever touches devices you are allowed to touch, checked on the server rather than in the browser.