Troubleshooting

Connecting to devices

Test Connection passes, but the device page stays empty

Check the RouterOS version on that device first. The manager needs RouterOS 7; RouterOS 6 is legacy and is neither tested nor supported. Test Connection opens a session and reads the basic system information, and a 6.x device can answer that much — which is why the test reports success on a device the rest of the page cannot be built from. What a given 6.x board does and does not answer beyond that is not something to work out here: RouterOS 6 is out of scope rather than diagnosed.

Moving the device to RouterOS 7 is the fix. Take a backup and an export first, and read MikroTik's upgrade notes, because part of the configuration is converted on the way. If the device has to stay on 6.x, the manager cannot manage it.

Test Connection fails, but I can log in to the router myself

Test Connection is not a ping. It opens a real session and reads the system information, so it fails whenever any part of that chain does not work — which is the point, but it does mean the failure could be one of several things.

Check, in this order:

• The port. The manager uses the port on the device form, not the one you happen to use in your terminal.
• The RouterOS user's group policies. A group without ssh and read cannot answer the read, even though the password is right — and that holds for a device set to REST as well, because the read is tried over SSH first. A device you write to over REST needs rest-api on the group on top of that.
• Any address restriction on the RouterOS user. If the account is limited to certain source addresses, the manager's address has to be one of them — and that is the container's address as the router sees it, which is not always the host's.
• The service itself on the router: SSH enabled for SSH devices, www-ssl or www for REST devices. On a REST device leave SSH enabled as well — the entry below explains why.

The error text returned by the test is the router's own, so it is worth reading rather than skipping.

The ready-made group, with everything the manager needs and nothing else, is on the Getting Started page. Use it as printed rather than trimming it: beside the obvious ssh, read and write, it carries reboot, which upgrades and restarts need, and sensitive, without which RouterOS hides sensitive values — a configuration export taken by that account would come back with the credentials blanked.

I set the device to REST — why does it still want SSH?

By design. The manager reads over SSH for every device and only sends writes over the configured method. MikroTik's REST API leaves an entry in /user/active roughly every ten minutes that is never cleaned up; left running long enough those entries exhaust the router's session slots. SSH creates one session that disappears on disconnect.

If SSH is unavailable on a REST device most reads fall back to REST, so the page still fills — but not all of them do. The bridge and VLAN views have no REST equivalent to fall back to, and a configuration export is taken over SSH whatever the device is set to. Upgrades are the other way round: they start on SSH for every device and only drop to REST if SSH throws. A REST device works better with SSH reachable, and your firewall rules should allow it.

The router has a self-signed certificate — is that the problem?

No. The manager accepts self-signed certificates on REST connections deliberately, because that is what a RouterOS device ships with. A failing REST device is failing for some other reason; work through the checklist above.

Status and monitoring

A device shows "Not accessible" but it is clearly up

The badge appears when the poll failed and the management port still accepted a TCP connection — the manager probes the SSH and API ports specifically to tell this case apart from a device that is really down, which shows a red Offline instead. What it does not prove is that your device is the one answering: a TCP handshake is accepted by whatever holds that address now, so a reassigned address, or a login the router has started refusing, arrives in the same amber badge.

When the router that answers reports a different serial number from the one on record, the manager can tell, and shows Other device instead (v1.96.0+). See the next question.

The case it was added for is the RouterOS session wedge: the router keeps forwarding traffic and answering on the network, but the part of it that serves console sessions stops responding, so nothing can query it. Winbox itself still connects, being a separate service, while a terminal window opened through it hangs exactly as a fresh SSH login does. The manager cannot clear that from the outside, and reports it honestly instead of showing the device as dead.

What does help is a second way in. If the device has an SNMP community, monitoring can be switched to SNMP — for the whole fleet in Settings, or for that one device on its form — and status, versions and traffic keep arriving while the console sessions are unresponsive, because SNMP is answered by a different part of the router. Commands, upgrades and backups still need a working session, so this keeps the device visible rather than manageable.

Worth knowing: the badge is also a webhook event, and its own one — a device that answers on the port but cannot be polled fires something different from a device that has gone off the network, so the two can be routed apart.

Readings have stopped changing

Two different faults look identical on screen, and they are worth separating before you investigate:

• Polling is failing. The device badge will have changed too. Start from the device, not from the browser.
• The live connection is down. Badges look normal but nothing moves, and a page reload shows fresh values that then freeze again. That is the WebSocket, not the router — see the next section.

By default a device is polled every 60 seconds. A device with its own poll interval set on the device form uses that instead.

A device shows "Other device"

The manager reached the address and a router answered, but it reports a serial number other than the one this device had. Usually the address moved: a DHCP lease went to another router, or a unit was swapped. Nothing that router reports is recorded under this device, and commands, upgrades and backups are not sent to it, so one router's data never lands under another's name. The device page says which serial number answered.

If the device itself has a new address, edit its Host; the next poll that finds the right serial number clears the badge. If the hardware was replaced on purpose, an admin can press Accept new serial on the device page, and the new board is taken as this device from then on. A board that reports no serial number, such as a CHR, is never flagged.

Reverse proxy and HTTPS

The interface loads through my reverse proxy, but nothing updates live

This is the most common reverse-proxy mistake. The manager pushes status changes, command output and upgrade progress over a WebSocket at /ws. If the proxy does not forward the WebSocket upgrade, everything renders correctly on load and then never changes.

Any proxy needs to pass the upgrade through. For plain nginx that means:

location /ws {
    proxy_pass http://<manager-host>:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

If you run SWAG, this is a complete working file — save it as /config/nginx/proxy-confs/manager.subdomain.conf and change the address to your own. SWAG's bundled proxy.conf carries the upgrade headers, which is why the block below does not repeat them:

## Place in SWAG at: /config/nginx/proxy-confs/manager.subdomain.conf
## Replace 192.0.2.10 with the host running the manager.
## In the SWAG container environment set: SUBDOMAINS=manager  VALIDATION=http

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name manager.*;

    include /config/nginx/ssl.conf;

    # Configuration backups and firmware uploads are not small.
    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;

        set $upstream_app 192.0.2.10;
        set $upstream_port 3000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }

    # Without this location the interface loads and then never updates.
    location /ws {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;

        set $upstream_app 192.0.2.10;
        set $upstream_port 3000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }
}

Or take the file directly: manager.subdomain.conf.

Add to Home Screen works, but the app shows a browser error page when the manager is unreachable

The offline shell needs a secure context. Over plain HTTP on a LAN address the browser does not merely refuse to register the service worker — the API for it is absent, which is a normal deployment rather than a fault. The icon and the full-screen window still work; what you do not get is the cached interface.

Serving the manager over HTTPS brings the shell back, but the certificate has to be one the browser trusts. The manager's own HTTPS listener, switched on with an environment variable and answering on port 3443, generates a self-signed certificate unless you give it one — and a browser treats that as an insecure page, so the worker is refused there just as it is over plain HTTP. A reverse proxy holding a real certificate is the straightforward answer; a certificate of your own, trusted on the devices that will use it, is the other. Note that the shell only ever caches the interface: nothing from the API is cached, so every reading on screen is live either way.

After upgrading, the interface does not load and shows a red error instead

The browser is holding parts of the previous release. The interface is loaded as one unit, so a single file left over from an older version stops all of it rather than breaking one panel — which is why the screen is an error message and not a partly working page.

From 1.85.2 the manager clears its own caches and reloads once when it detects that the interface never started, so this should resolve itself as soon as you open it. That recovery is deliberately narrow: it fires only when nothing came up at all, and not more than once a minute, so an error with the app already on screen never reloads the page out from under you. If the screen stays, use the Clear cache and reload button on it. Failing that, clear the site's data in the browser by hand — on a phone with the app on the home screen, remove the icon and add it again.

If it recurs on every release, the cause is almost always a proxy or CDN in front of the manager that serves the interface files from its own cache. The manager marks them as needing revalidation; a proxy configured to override that will keep handing out old copies. Exclude the manager from that caching, or set it to respect the origin's headers.

Missing or empty data

An SNMP device shows much less than the others

Expected. Over SNMP the manager reads version, uptime, CPU load, memory, board name and model, serial number, software ID on RouterBOARD hardware, current and upgradeable firmware, temperature, voltage, power consumption, identity, the interface list with neighbours, and traffic counters.

Commands, upgrades and backups are not available over SNMP at all — an SNMP-only device is a monitoring target. Its Logs tab still works, because syslog is sent by the device rather than read from it. If you need the rest, give the device an SSH or REST method; SNMP can stay on as a supplementary source.

A PoE switch shows its draw but no budget bar

RouterOS reports how much power is going out, but never how much the switch is allowed to deliver — that figure is a datasheet property, so the manager keeps a table of it per model. If your board is not in that table, you get the measured draw and no bar, which is deliberate: borrowing a similar model's ceiling would look exactly like a real reading.

Switches powered from an external supply need one more thing: their limit is a current, so the budget is that current multiplied by a voltage. The device usually reports the voltage itself; where it does not, tell the manager which power supply the switch runs on and it takes the voltage from there.

The PoE-out supply field in the device form lists MikroTik's supplies by name — 18POW, 24HPOW, 48POW, 48V2A96W, MTP250 and the rest — and takes a plain volts-and-amps pair for anything else. That is also what gives routers with PoE-out a budget at all: their ceiling depends on the brick, so without one there is nothing honest to draw.

The budget does not match the figure on the product page

Usually because the product page figure assumes something your unit does not have. A CRS320-8P-8B has 963 W of PoE capability but ships with a 600 W supply, so with one PSU fitted the manager shows 600 W; fit the second and it reads the change from the device itself. A CRS112-8P is rated 2.8 A, which is 78 W on a 28 V supply and about 74 W on 53 V — the same switch, different ceiling, and the manager uses the voltage the device actually reports.

Some models also have a limit the total does not show. A CRS328-24P is three independent groups of eight ports at 150 W each, so the card draws a bar per group: a switch comfortably under its 450 W total can still run one group out of power.

A supply smaller than the board can lower the ceiling too. A CRS112-8P on 57 V would pass nearly 80 W by its own current limit, but not through a 70 W adapter, and the card says which of the two it is showing. An RB5009UPr+S+IN is a third case: MikroTik publishes a 130 W total and states that the board keeps 20 W for itself, so with the 96 W adapter it ships with, 76 W is what remains for the ports. Fit a larger supply and it climbs to its 130 W limit. With no supply named, the manager assumes the bundled one and says so on the card.

The budget has plenty left but a powered device will not start

Check the voltage before the watts. Passive PoE-out carries whatever voltage the board itself is fed — MikroTik states it plainly on its PoE-Out page: the output voltage depends on the power source connected to the PSE. A board running on a 24 V supply cannot present a higher one, so a device that needs the high-voltage class will not come up however much of the budget is free.

From 1.75.0 the card says so: when the supply is below the high-voltage class, a line under the figure states the voltage and that only devices accepting passive PoE at that voltage will start. The watts on the bar are still correct — they are just not the limit you are hitting.

The card says the board reports a different voltage than the supply I chose

It means the two disagree by voltage class — one is a low-voltage supply (up to 30 V) and the other a high-voltage one (48 V and above) — and almost always that the supply was swapped and the PoE-out supply field was not updated. Until it is, the budget is worked out from a supply that is not plugged in.

Normal variation does not trigger this. A 24 V supply sits around 24.5 V on the rail and a 48 V one around 53 V; the check only fires when the reading and the selection fall on opposite sides of that divide. Set the field to the supply actually fitted and the message clears. The manager does not silently correct the figure for you: it cannot tell from a voltage how many amps a supply has, so the budget keeps following what you told it and says that it is contradicted.

Power consumption on a PoE switch reads differently since 1.71.0

They are two separate readings and the card keeps them apart. Power consumption is what the board itself draws; what it is handing out to powered devices is the PoE figure, and that lives on the PoE Budget card. A switch delivering 28 W of PoE while drawing some 60 W of its own is showing you both, in the two places they belong. On a board that publishes no overall consumption sensor there is simply no board figure to show.

History recorded before the update keeps the values it holds, so the graph can step at the point you updated. Nothing was rewritten.

The topology map shows no links, or will not stop scanning

An empty map is often the correct answer: neighbour discovery does not cross a router, so a site holding one device — or devices in different locations — has nothing to draw. The panel beside the map reports what the scan actually saw, including which of the site's devices were offline and whether the Unmanaged filter is hiding anything, and Topology works through the full checklist, starting with discover-interface-list on the ports that carry the links.

A map that seems stuck on a scan is usually not. A re-scan never blanks the page: the last result stays on screen and is swapped for the new one when it lands, while the button reads Scanning…. A spinner in place of a map means this site has never been scanned at all, and if a scan has not landed after about two minutes the page stops waiting — Refresh starts it again.

An upgrade is refused and the network is fine

Check the device-mode value in the strip at the top of the device page. Every RouterOS board carries an allowed-versions range and an install-any-version switch, both part of device-mode, and a version outside that range is refused by the router itself — not by the manager and not by the network. Hover the device-mode value to see the range the board accepts.

Device-mode also decides which features exist at all, so the same setting explains a bandwidth test, sniffer or traffic generator that will not start. Changing it requires physical confirmation at the device — a button press or a power cycle — which is why the manager reads it and never writes it.

A tab on the device page is empty

Usually the hardware simply does not have that feature. A router with no wireless has no wireless clients; a board with no health sensors reports no temperature or voltage; a CHR has neither a routerboard section nor health readings. The manager asks and shows what comes back, so an absent feature reads as an empty section. A sensor that is not fitted answers zero rather than nothing, and those zeros are left out instead of being charted as a flat line — a CPU load of zero, which is a real reading on an idle router, is kept.

Nor is there anything to find in the router's own log. A command a board does not understand is asked once, and after that the manager remembers and stops asking it of that device, so an empty tab is not filling the log with errors for you to catch.

The distinction that matters: an empty section with the rest of the page populated is almost always missing hardware. A page where everything is empty is a connection problem — start at the top of this page.

Reporting a problem

If none of the above fits, a report is genuinely useful — most of the entries on this page exist because somebody sent one. Include:

• The manager version, from the interface.
• The RouterOS version and the board name of the device involved.
• The device's connection method, and whether SNMP is also configured.
• The exact error text, rather than a description of it.

Write to support@mikr.app. If you already use GitHub, an issue works just as well — but an email is not the lesser channel, and no account is needed for it.