One router, everything the manager knows about it. The page is built from what the device actually reports, so two routers rarely show the same set of tabs — and an absent tab is usually the answer to "why can I not see X here".
Five metric cards run across the top — CPU, RAM, temperature, voltage and uptime — with temperature and voltage hidden on boards that report no such sensor. Below them a strip carries the host, board name, architecture, connection method, RouterOS version and the time of the last successful poll.
Two banners appear here when they apply, and both are worth reading rather than dismissing:
write policy. Monitoring and every read tab keep working; commands, upgrades, service toggles and backups will be refused by the router itself, whatever your role in the manager is.A third note appears where routine polling has been moved to SNMP: SSH or REST is then opened only when you open a detail tab or run an action.
The Services strip shows which of the RouterOS IP services are enabled, and an administrator can toggle one from here. If NVD advisories match the running version, a Security Advisories card sits above the interfaces — the Security page explains where those come from.
The Interfaces card lists the ports with their state, addresses and, on PoE boards, the per-port power draw. Clicking an interface opens the traffic card beneath it.
The card is read-only until you turn on Edit mode, which opens the VLAN editor: VLANs and a role per port, written to the device behind a preview, a backup and a rollback the device performs on its own if you do not confirm. It has a page of its own.
That card has two clocks. Live polls the device every two seconds for as long as somebody is watching, and stops when the last viewer closes the card or leaves the page — nothing is sampled at that rate in the background. The 1h, 6h, 24h and 7d ranges read stored history instead, sampled once a minute and kept for seven days by default. Anything beyond that window has been pruned, which is why the 7d range is the longest one offered.
The chart shows RX and TX with the peak and current scale beside them, and hovering reads off a single point.
When the selected interface carries an SFP module, a Traffic/Optical switch appears on the same card. The optical view charts three things from the module's own diagnostics — receive and transmit power in dBm, module temperature, and supply voltage — over 6 hours, 24 hours, 7 days or 30 days.
These samples come from the five-minute metric tier, not the traffic tier, so they are kept for ninety days by default rather than seven. A slowly falling receive level over a month is exactly the shape this view exists to make visible.
SFP and SFP+ ports report themselves as ordinary ethernet in RouterOS, so the switch appears based on whether a module is actually present, not on the port's type.
On boards with PoE-out, a budget card sits above the interfaces: total draw, the ceiling, the percentage between them, and how many ports are actually powered. A port configured for PoE but feeding nothing reads zero watts and counts as unpowered — a forced-on port with nothing plugged in is not a load.
Where the draw figure comes from depends on the board. If it reports its own consumption meter, that wins, because it counts losses the per-port readings miss; otherwise the ports are summed. The card says which of the two you are looking at.
The ceiling has four possible origins, and the card names the one in use rather than presenting a bare number:
| Origin | What it means |
|---|---|
| Set by hand | A budget entered on the device form. It overrides everything below |
| Fitted PSUs | Models where the ceiling follows how many power supplies are installed |
| The selected supply | An external supply chosen on the device form, or its amps and volts — the budget is then whichever is lower, the supply or the board |
| The model datasheet | A fixed figure published for that board |
Switches with several PSE blocks get a bar per block as well as the total: a 450 W switch with a 150 W ceiling per group of eight ports can be within budget overall and over it on one block.
Two things the watt figure alone cannot tell you are called out separately. A board powered from a low-voltage rail passes that voltage through to its PoE-out ports, so the constraint is not headroom but which powered devices will start at all. And where the voltage the board reports does not match the supply selected on the form, the card says so — that is the swapped-brick case the picker cannot catch on its own.
A model nobody has run on real hardware yet carries an "unverified" badge. It means the figures come from the datasheet alone, not that they are wrong.
Below the traffic card, a chart card draws history from five-minute samples, kept for ninety days by default. What it can draw is whatever the board reports — every sensor in its health table, from temperature and voltage to fan speed in RPM — plus CPU load and memory usage, which are derived from the poll and therefore available on every model and every transport.
The card appears only once something has actually been sampled, and it is deliberately not tied to the device being online. "What was the CPU doing before it stopped answering" is the question you ask about a router that is already down.
Points are placed at the time they were taken, and the line breaks wherever sampling stopped for longer than two intervals, with the number of gaps stated above the chart. A stretch with no samples therefore reads as missing rather than as a slow, steady line across it — which is what an index-spaced chart drew before, at exactly the width of one ordinary step. The same is true of the interface traffic chart, the optical chart and the small sparklines beside each interface.
One card near the bottom carries the interactive tabs. Command, History, DHCP Leases and Wi-Fi are always there for a device the manager can talk to; Logs appears when the syslog receiver is enabled; and IPsec, WireGuard, IPv6 Neighbors, LTE, STP and Routing are added only when the device reports the corresponding feature.
Tabs load when you open them and not before, and the open tab refreshes every thirty seconds while it stays open. Switching away stops that polling — the page does not keep six tabs' worth of queries running against a router.
The whole card is for operators and administrators. A viewer does not get it, including the Command tab, which runs a single command against this one device and prints the output beneath.
The History tab lists this device's command runs, including the ones started from the Commands page.
The DHCP tab lists the leases with their addresses, MACs, host names and expiry. Adding a lease, or converting a dynamic one to static, is an administrator action.
Above the table, each DHCP server gets a utilisation bar against the address pool bound to it: green, amber above 75 per cent, red above 90. What is counted is pool addresses taken, not lease rows. Those are different numbers, and the difference is the whole point: static leases normally sit outside the pool entirely, and two rows can name one address. Counting rows made pools look full while addresses in them were free.
Where there is no pool to measure against — a server handing out static leases only, or an IPv6 pool — there is no bar, only a lease count. A capacity the manager cannot work out is shown as no capacity rather than as a guess.
The Wi-Fi tab has two parts: the connected clients, refreshed with the tab, and above them the security profiles with their SSIDs.
Passwords in that table are write-only. The current passphrase is never read from the device and never displayed — an administrator can set a new one, and that is all. Profiles using EAP rather than a pre-shared key are shown as such, with nothing to change here.
Changing a password covers the modern /interface wifi stack. Legacy wireless and CAPsMAN profiles are not listed.
The IPsec tab lists peers with their policies. Each selector's status comes from that policy's own phase-2 state rather than from matching addresses against the peer, and selectors are grouped by name — which is what makes a multi-selector peer readable instead of a flat list.
The WireGuard tab lists peers with their allowed addresses, endpoint and last handshake. Adding a peer is an administrator action.
The IPv6 Neighbors tab is the device's neighbour discovery table with each entry's state — reachable, stale or failed. IPv6 routes are not separate; they live in the Routing Table card, under its IPv6 switch.
On a device with an LTE interface, the LTE tab shows the modem and the radio: RSRP, RSRQ, SINR and RSSI, the cell and eNB identifiers, sector, LAC, session state, IMEI and modem firmware, with a button to start a modem firmware upgrade.
If an OpenCelliD key is configured in Settings, the tab also resolves the serving cell to approximate coordinates and links out to a map. That lookup is asynchronous and never blocks the rest of the tab: signal figures appear immediately whether or not the lookup succeeds.
Two more panels live under the same tab. Monthly data usage accumulates transfer against the limit set on the device form, and fires a webhook as the limit approaches and again when it is crossed. The SMS inbox lists messages received by the modem, with a badge showing whether reception is switched on at the RouterOS end and on which port.
The Routing tab appears when the device has BGP connections or OSPF neighbours. BGP peers are listed with their remote address, remote AS, state, uptime and prefix count; OSPF neighbours with their address, router ID, state, adjacency, priority and area.
Clicking a peer row charts it. The BGP history card underneath draws that peer's prefix count and session state over 6 hours, 24 hours, 7 days or 30 days, from five-minute samples kept for ninety days by default. The table refreshes every thirty seconds; the chart, being a five-minute tier, refreshes every five.
The strip under the line is the session state over time: green up, red down, grey for a peer an operator disabled, and blank where there are no samples at all. It is drawn to scale, so an hour of downtime is an hour wide and time nobody measured stays empty rather than being filled in by the samples on either side. The summary above the chart states down and disabled time as durations, and says plainly when part of the range has no samples — it will not claim "no downtime" about a stretch it cannot see.
Each sample also records how long the session had been up. Two samples five minutes apart can both say "up" with a full outage between them; a session uptime that went backwards is the only trace such a reset leaves, and it is what the BGP Session Down webhook fires on as well as on a peer that is simply down. One case is deliberately quiet: rebooting a router resets every session on it, so a fallen uptime there says nothing about the peer. The device's own uptime settles it, and a restart silences the peers on that device rather than reporting one flap each.
The inventory is keyed on the BGP connection, not the session, and that distinction matters. RouterOS lists only sessions that exist — a peer that goes down disappears from that table altogether. Keyed on sessions, a peer vanished from the history instead of recording a session that was down, and an outage was drawn as a flat line with no gap in it. Connections are configuration and never vanish, so a down peer records as down. The connection name is also the name RouterOS writes in its own log, so the chart and the device's log agree with each other.
Tabs are added from a capability probe run when the page opens, against a device that is online and enabled. That gives three ordinary reasons for an absent tab:
A tab that is present but empty is a different problem — that one is covered on the Troubleshooting page.