System Health and Resource Monitoring

System Health and Resource Monitoring

RouterOS exposes two complementary monitoring interfaces: /system/resource for software-level counters (CPU, memory, storage, uptime) and /system/health for hardware sensor readings (temperature, voltage, fan speed). Together they give you a complete picture of router state, and both are scriptable for automated alerting.

System Resource

/system/resource reports operational counters that are available on every RouterOS device regardless of hardware.

Sub-menu

/system/resource

Reading Resource Data

/system/resource/print

Example output:

                   uptime: 2w3d14h22m11s
                  version: 7.14.3 (stable)
               build-time: 2024-03-01 07:27:53
         factory-software: 7.4.1
              free-memory: 412.8MiB
             total-memory: 512.0MiB
                      cpu: Intel(R) Atom(TM)
                cpu-count: 2
             cpu-frequency: 1333
                 cpu-load: 7%
           free-hdd-space: 18.6MiB
          total-hdd-space: 128.0MiB
  write-sect-since-reboot: 12854
         write-sect-total: 48291
        architecture-name: x86_64
              board-name: CHR
                 platform: MikroTik

Resource Properties

Property	Description
uptime	Time since last reboot
version	RouterOS version string
free-memory	Available RAM
total-memory	Total installed RAM
cpu	CPU model/description
cpu-count	Number of logical CPU cores
cpu-frequency	CPU speed in MHz
cpu-load	Current CPU utilisation (percent, 1-second average)
free-hdd-space	Available flash/disk storage
total-hdd-space	Total flash/disk capacity
write-sect-since-reboot	Storage writes since last boot (wear tracking)
write-sect-total	Cumulative storage writes since manufacture
architecture-name	CPU architecture (arm, arm64, x86_64, mipsbe, tile, etc.)
board-name	Hardware model identifier
platform	Platform family (MikroTik, CHR, etc.)

Retrieving Individual Fields

Use get to read a single value — convenient in scripts:

:put [/system/resource/get cpu-load]
:put [/system/resource/get free-memory]
:put [/system/resource/get uptime]
:put [/system/resource/get free-hdd-space]

Per-CPU Load

On multi-core devices you can inspect per-core utilisation:

/system/resource/cpu/print

# CPU  LOAD  IRQ  DISK
  0     12%   1%   0%
  1      8%   0%   0%

Calculating Memory Usage Percentage

RouterOS does not report used-memory directly. Calculate it from the available fields:

:local free [/system/resource/get free-memory]
:local total [/system/resource/get total-memory]
:local usedPct (100 - (($free * 100) / $total))
:put ("Memory used: " . $usedPct . "%")

---

System Health

/system/health reads hardware sensor data from the RouterBOARD monitoring chip. Available sensors depend on the physical device — run print to see what your hardware exposes.

Note

/system/health was introduced in RouterOS v6.44. CHR (Cloud Hosted Router) has no physical sensors; the menu returns no entries or only virtualised readings.

Sub-menu

/system/health

Reading Health Data

# All sensors at once
/system/health/print

Typical output on a CCR2004:

   NAME                    VALUE UNIT
   temperature             47    C
   cpu-temperature         52    C
   fan1-speed              2200  RPM
   fan2-speed              2150  RPM
   voltage                 24.1  V

# Live polling (press Q to exit)
/system/health/monitor

# Read a single sensor in a script
:put [/system/health/get temperature]

Health Sensor Properties

Property	Unit	Description
temperature	°C	Main board temperature
cpu-temperature	°C	CPU core temperature (supported devices)
temperature-1, temperature-2	°C	Additional sensors on multi-sensor boards
voltage	V	Input supply voltage
poe-out-voltage	V	PoE output voltage (PoE-capable ports)
fan-speed / fan1-speed / fan2-speed	RPM	Fan tachometer readings
fan-status	—	ok or fault

Not all properties appear on all devices.

Typical Temperature Ranges

Condition	Range
Optimal	20 °C – 40 °C
Normal	40 °C – 60 °C
Elevated	60 °C – 70 °C
High	70 °C – 80 °C
Critical	Above 80 °C

Consult your device’s hardware manual for rated operating limits.

Platform Sensor Availability

Feature	Entry-level (hEX, RB9xx)	Mid-range (RB4011, CCR1009)	High-end (CCR2004+, CRS3xx)
Board temperature	Yes	Yes	Yes
CPU temperature	No	Yes	Yes
Multiple temperature sensors	No	Partial	Yes
Input voltage	Yes	Yes	Yes
PoE voltage	No	Partial	Yes
Fan speed monitoring	No (fanless)	Partial	Yes

---

Threshold Alerting via Scripts

RouterOS has no built-in alarm system for resource or health thresholds. The standard pattern is a Scheduler-driven Script that reads values and acts when limits are exceeded.

Basic CPU and Memory Alert

/system/script/add name=resource-check source={
    :local cpu [/system/resource/get cpu-load]
    :local free [/system/resource/get free-memory]
    :local total [/system/resource/get total-memory]
    :local usedPct (100 - (($free * 100) / $total))

    :if ($cpu > 85) do={
        :log warning ("High CPU: " . $cpu . "%")
    }
    :if ($usedPct > 90) do={
        :log warning ("High memory usage: " . $usedPct . "%")
    }
}

/system/scheduler/add name=run-resource-check interval=1m on-event=resource-check

Temperature Alert with Email

Configure SMTP first:

/tool/e-mail/set \
    server=smtp.example.com \
    port=587 \
    from[email protected] \
    user[email protected] \
    password=<password>

Then add the alert script:

/system/script/add name=temp-alert source={
    :local host [/system/identity/get name]
    :local temp

    # Handle devices where temperature sensor may be absent
    :do {
        :set temp [/system/health/get temperature]
    } on-error={
        :set temp -1
    }

    :if (($temp != -1) && ($temp > 70)) do={
        :log warning ("High temperature: " . $temp . "C")
        /tool/e-mail/send \
            to="[email protected]" \
            subject=("Temperature alert: " . $host) \
            body=("Board temperature is " . $temp . "C on " . $host)
    }
}

/system/scheduler/add name=run-temp-alert interval=2m on-event=temp-alert

Stateful (Transition-Only) Alerts

The simple approach sends an alert every polling cycle while the threshold is breached. Use global variables to send only on state transitions — equivalent to Netwatch up/down behaviour:

/system/script/add name=cpu-stateful-alert source={
    :global cpuAlarmActive

    :if ([:len $cpuAlarmActive] = 0) do={
        :set cpuAlarmActive false
    }

    :local cpu [/system/resource/get cpu-load]
    :local host [/system/identity/get name]
    :local alarmThreshold 85
    :local clearThreshold 75

    # Rising edge: normal → alarm
    :if (($cpu > $alarmThreshold) && ($cpuAlarmActive = false)) do={
        :set cpuAlarmActive true
        :log warning ("CPU alarm ON: " . $cpu . "%")
        /tool/e-mail/send \
            to="[email protected]" \
            subject=("CPU alarm ON: " . $host) \
            body=("CPU load is " . $cpu . "% on " . $host)
    }

    # Falling edge: alarm → normal
    :if (($cpu < $clearThreshold) && ($cpuAlarmActive = true)) do={
        :set cpuAlarmActive false
        :log info ("CPU alarm cleared: " . $cpu . "%")
        /tool/e-mail/send \
            to="[email protected]" \
            subject=("CPU alarm cleared: " . $host) \
            body=("CPU load recovered to " . $cpu . "% on " . $host)
    }
}

/system/scheduler/add name=run-cpu-stateful interval=1m on-event=cpu-stateful-alert

The separate alarm and clear thresholds (85% trigger, 75% clear) add hysteresis and prevent alert storms during borderline conditions.

Combined Health and Resource Check

/system/script/add name=full-health-check source={
    :local host [/system/identity/get name]
    :local cpu [/system/resource/get cpu-load]
    :local free [/system/resource/get free-memory]
    :local total [/system/resource/get total-memory]
    :local usedPct (100 - (($free * 100) / $total))
    :local temp; :local volt

    :do { :set temp [/system/health/get temperature] } on-error={ :set temp -1 }
    :do { :set volt [/system/health/get voltage] } on-error={ :set volt -1 }

    :if ($cpu > 85) do={
        :log warning ("ALERT " . $host . ": CPU=" . $cpu . "%")
    }
    :if ($usedPct > 90) do={
        :log warning ("ALERT " . $host . ": Memory=" . $usedPct . "%")
    }
    :if (($temp != -1) && ($temp > 70)) do={
        :log error ("ALERT " . $host . ": Temperature=" . $temp . "C")
    }
    :if (($volt != -1) && ($volt < 11)) do={
        :log error ("ALERT " . $host . ": Voltage=" . $volt . "V")
    }
}

/system/scheduler/add name=run-full-health-check interval=2m on-event=full-health-check

---

Built-in Graphing

RouterOS can generate and serve traffic and resource graphs over HTTP without any external tool.

Enable Resource Graphing

# Set storage interval (how often data points are recorded)
/tool/graphing/set store-every=5min

# Add a resource graph (CPU and memory)
/tool/graphing/resource/add allow-address=192.0.2.10

# Add an interface traffic graph
/tool/graphing/interface/add interface=ether1 allow-address=192.0.2.10

Viewing Graphs

Access graphs via the router’s web interface:

http://<router-ip>/graphs/

Graphs are available only to addresses listed in allow-address. Replace 192.0.2.10 with your management workstation IP or use 0.0.0.0/0 for unrestricted access (not recommended on untrusted networks).

---

SNMP Polling

SNMP enables external monitoring systems (Zabbix, Grafana, Prometheus, MRTG) to poll RouterOS metrics.

Configure SNMP

# Create a read-only community restricted to your monitoring host
/snmp/community/add name=monitor addresses=192.0.2.10/32 read-access=yes

# Enable SNMP service
/snmp/set enabled=yes contact="NOC" location="Site-1"

RouterOS exposes CPU and memory through the standard HOST-RESOURCES-MIB and interface counters via IF-MIB. MikroTik-specific metrics (health sensors, routing tables) use the vendor MIB tree under OID prefix 1.3.6.1.4.1.14988.

SNMP v3 (Recommended)

/snmp/community/add \
    name=monitor-v3 \
    security=private \
    authentication-protocol=SHA1 \
    authentication-password=<auth-pass> \
    encryption-protocol=AES \
    encryption-password=<enc-pass>

External Monitoring Integrations

Tool	Integration method
Zabbix	Add as SNMP host; use MikroTik Zabbix template
Grafana	SNMP → Prometheus (snmp_exporter) or InfluxDB → Grafana dashboard
Prometheus	RouterOS exporter (e.g. mikrotik-exporter) scrapes API or SNMP
MRTG	Classic SNMP polling for interface counters and system metrics
The Dude	Native MikroTik NMS with built-in RouterOS device support

RouterOS does not push metrics to Grafana directly. The typical pattern is: SNMP or API collection into a time-series database, then Grafana visualisation.

---

Troubleshooting

High CPU Load

1. Check which processes consume CPU: /system/resource/cpu/print
2. Review active connections: /ip/firewall/connection/print count-only
3. Check for scanning/flood traffic with Torch: /tool/torch interface=ether1
4. Disable connection tracking if not needed: /ip/firewall/connection/tracking/set enabled=no

High Memory Usage

1. Check active connections and routes — large tables consume significant RAM
2. Review DNS cache size: /ip/dns/print → cache-used
3. Check queue tree size: /queue/tree/print count-only
4. Reduce log memory buffer if large: /system/logging/action/set memory max-messages=100

High Temperature

1. Verify adequate airflow — check for blocked vents or cable obstruction
2. Confirm ambient temperature is within spec
3. Check fan speed: /system/health/print
4. Review PoE output load and reduce if possible
5. Inspect the device for dust accumulation

Sensor Not Appearing in /system/health

Not all devices have all sensors. Run /system/health/print to see what your hardware exposes. If an expected sensor is missing, it is either not present on this model or requires a RouterOS upgrade.

---

Related Features

• Logging — configure where log messages go (memory, disk, syslog, email)
• Netwatch — monitor external host availability with up/down scripts
• Scheduler — automate recurring scripts
• SNMP — enable SNMP polling for external monitoring systems
• Graphing — built-in HTTP graph server
• E-mail Tool — SMTP client for script-driven alert delivery