Upgrades

Checking for updates

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 five devices at a time from a pool that refills as slots free up — a new device starts as soon as one finishes, so 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.

Reading the release notes first

A version number does not say whether you want it. The Upgrades page carries a badge for the newest release on each of the four channels, and clicking one reads that version's RouterOS changelog without leaving mikr. On a single device, What's new sits inside the update dialog, beside the options.

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.

The three upgrade actions

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 three are buttons on the Upgrades page, where you are acting on a selection of devices, and each asks you to confirm the selection before anything starts. On a single device's own page the same choice arrives differently: when a check finds an update, one Update button appears carrying the version it would install, 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.

A plain Reboot is not one of these. It is a single-device action and it lives on the device's own page — and as a swipe action in the phone device list — because it installs nothing. The connection dropping is treated as success, because that is what a reboot looks like from outside.

Whichever way a device is managed, the install itself is attempted over SSH first, and the REST API is used only when SSH cannot be reached on a device set up for REST. It is worth leaving SSH open on anything you intend to upgrade.

Picking devices

The box above the table narrows it before you select. A plain word matches a device's name, identity, address, site or model, and anything shown in its row, so Available or 7.19 work too. To be precise, name a field: name:, host:, site:, model:, ros: for the installed RouterOS version, fw: for firmware, channel: for the update channel, tag:, and status: followed by behind, fw-behind, current, unchecked, online or offline. Several terms narrow together, and each value is a regular expression, so name:^cpe1 model:hap status:behind means what it reads as. (v1.88.0+)

A device the filter hides is also deselected, and every bulk button acts only on what is shown, so nothing out of sight is upgraded. The same box appears in the queue, the schedule picker, on the Commands page and in the template dialog.

Changing the update channel

Every device follows one of RouterOS's four update channels: stable, long-term, testing or development. A check or an upgrade only ever sees what that channel offers. The channel is the badge next to the installed version in the table.

To change it, select the devices and press Change channel…. The dialog lists every selected device with its current channel and the one it will move to, and nothing is written until you confirm that list. Devices that will not be changed stay in the list, greyed out, with the reason: offline, disabled, SNMP-only, a read-only RouterOS account, or already on that channel. A device whose channel has not been read yet shows it as unknown and is changed like any other. (v1.91.0+)

Going back is the same action. The last entry in the target list, Previous channel, returns each device to the channel it was on before mikr last changed it. It works per device, so a batch that mixed stable and long-term goes back to both. A device whose channel mikr has never changed has no previous channel and is left alone.

Changing a channel installs nothing. Each device checks for updates on its new channel straight away, so the table shows what the new channel offers, not what the old one did. If that check does not confirm the new channel, the device is reported as failed. The dialog warns when the target is testing or development, and it names devices that have a scheduled or queued upgrade without a pin: that upgrade will install whatever the new channel offers.

Moving to a channel with an older release does not roll a device back. Upgrades from the buttons, the queue and schedules all skip a device that already runs something newer than its channel offers, and the device stays on its version until the channel catches up. mikr does not downgrade RouterOS.

The table shows the channel the device reported the last time it was polled over SSH or REST, or checked for updates. For a device polled over SNMP, only a check refreshes it, so run Check for Updates first if the channel shown may be out of date.

Changing a channel needs the admin or operator role and stays within your site scope, the same as upgrading. The activity log records both the request and the channel each device ended up on.

The sequential queue

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.

Filling the queue

Devices go into the queue by dragging them from the list on the left, or by clicking one to append it. For a fleet-wide run there is Add all needing update above that list: it queues every online device that is behind in one press, and the number on the button is the number it will add. (v1.81.0+)

A device dropped onto the queue lands where you drop it, above or below the row under the pointer, and the strip under the list adds at the end. The list on the left takes the same filter as the Upgrades table: Add all shown queues everything the filter leaves, and Add all needing update counts only those. (v1.88.0+)

What counts as behind follows the RouterOS / Firmware / Both choice next to the queue, and it is the same judgement the Upgrades table shows as Available — a device already running a newer version than the update it last heard about is never added, and if one is queued by hand anyway, it is skipped when its turn comes. A device that has never been checked for updates says nothing either way; those are left out rather than treated as up to date, and the confirmation tells you how many were passed over. Run Check for Updates on the Upgrades tab first if you want them included.

PoE-aware ordering

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.

When a device stops responding

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+)

Stopping after too many failures

A release that breaks on your hardware, or a configuration it does not agree with, should reach as few devices as possible. Under Settings → Safety stop an administrator can set how many failed devices end an upgrade run, a percentage of the run's devices, or both; both are off until set. A single run can set its own count in the field beside the queue's start button, or beside the upgrade buttons above the table, and 0 there turns the stop off for that run. (v1.88.0+)

The queue upgrades one device at a time, so it stops exactly at the limit and cancels the devices still waiting. The upgrade buttons above the table work through several devices at once: when the limit is reached no further device is started, the ones already upgrading are left to finish, since cutting an install off midway is worse, and the rest are reported as held. The percentage is a share of every device in the run, not of those tried so far: at 5%, a run of 200 devices stops at its tenth failure, wherever in the run it happens. A run too small for the percentage to allow even one failure stops at the first, so for a small run the count is the better limit. (v1.89.0+)

By default a safety stop also pauses scheduled upgrades, so the same release is not sent out again at the next scheduled time. The Schedule tab then says so and offers Resume. A queue in which any device failed finishes marked as failed.

Cancelling

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.

Scheduled upgrades

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. The list shows the RouterOS version each device is on and the latest it knows about, so you can tell at a glance whether a scheduled upgrade is still needed.

There are two ways to create one. On the Upgrades table, select the devices as you would for an immediate upgrade — the filter and the site checkboxes apply — and press Schedule…, which asks only for the time and the upgrade type; as with every bulk action there, only devices visible under the current filter are taken. The Schedule tab also has a device picker of its own for the same job. A device holds one schedule at a time, so scheduling it again moves it rather than adding a second run.

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.

Pinning the version

RouterOS installs whatever its update channel offers at the moment the upgrade runs, so a release published between scheduling and the maintenance window would go out without anyone having read it. Every way of scheduling offers Pin to the version available now, which ties each device to the RouterOS version it was last offered. When the time comes the device checks again, and if its channel offers anything other than that version it is held: nothing is installed, the firmware step is skipped with it, and the log names both versions. A device already on the pinned version, or past it, is skipped. (v1.88.0+)

A pin cannot make RouterOS install a particular release; it can only decline a different one. It also needs a version to pin to, so run Check for Updates on the devices first — a pinned schedule is refused, naming the devices, if any of them has never been checked. Firmware-only schedules are not pinned, because firmware follows the installed RouterOS.

Scheduling a saved queue

A queue you have arranged can be saved as a preset and loaded again later — useful for a run you repeat, such as a monthly pass over the branch routers. From 1.86.0 a preset can also be given its own time: open Manage… beside the preset picker and press Schedule… on the preset you want.

The difference from scheduling devices one by one is the order. A preset keeps the sequence you arranged, so a run built around which device powers which arrives at its window intact rather than being reassembled. It runs once, and the pending time is shown on the preset with a Clear button beside it. Devices you deleted or disabled in the meantime are skipped and the rest keep their places; if a queue happens to be running when the time comes, the preset waits and starts once that queue is finished.

Watching a run

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.

When an upgrade is refused

Two refusals are deliberate and worth recognising:

• A read-only RouterOS account. If the account stored for the device has no write policy, the upgrade is refused up front rather than attempted and failed halfway. The device carries a read-only badge for exactly this reason — see the account setup.
• Your role. Upgrading and changing the update channel require the admin or operator role; a viewer can see versions and what is available, and nothing more. See Users and access.

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.