Logging

Logging

RouterOS logging captures system events, errors, and operational messages that help with monitoring and troubleshooting. The logging system consists of three components: messages tagged with topics, rules that select which messages to forward, and actions that define where messages are sent.

How Logging Works

Every log message in RouterOS carries one or more topics that identify its source subsystem and severity level. Rules match incoming messages by topic and forward them to a named action. An action defines the destination: RAM buffer, disk file, remote syslog server, or email.

Log message (tagged with topics)
    ↓
Rules (/system logging) — match by topics
    ↓
Actions (/system logging action) — send to destination

A message is only stored or forwarded if at least one rule matches it. By default, RouterOS ships with rules that send most messages to the built-in memory action (the in-RAM buffer viewable with /log print).

Viewing Logs

Sub-menu path: /log

Log entries stored in memory by the memory action can be viewed in the CLI or WinBox.

CLI

# Print all logs (paged)
/log print

# Print without paging (useful in scripts)
/log print without-paging

# Follow live log output (Ctrl+C to stop)
/log print follow

# Filter by topic
/log print where topics~"error"
/log print where topics~"warning|critical"
/log print follow where topics~"firewall"

# Filter by message content
/log print where message~"login failed"
/log print where message~"192.168.1"

WinBox

Open the Log window from the main menu. Use the search/filter bar at the top to narrow entries by topic or message text. Color coding highlights different severity levels.

Log Entry Format

Each log entry contains three fields:

Field	Description
time	Timestamp of the event (wall clock, or uptime if the system clock has not been set)
topics	Comma-separated list of topic tags, e.g. system,info,account
message	Human-readable description of the event

A prefix configured on a logging rule is prepended to the message, useful for identifying which rule captured a given entry.

Log Topics and Severities

Topics serve a dual purpose: they identify the subsystem that generated the message and the severity level. Severity topics are:

Topic	Meaning
critical	Critical system failures requiring immediate attention
error	Errors that may affect functionality
warning	Non-critical issues worth noting
info	Normal operational information
debug	Verbose diagnostic output (high volume)

Common subsystem topics include:

Topic	Subsystem
account	User login and authentication
bgp	BGP routing protocol
caps	CAPsMAN controller events
dhcp	DHCP server and client
dns	DNS resolver
e-mail	Email tool
firewall	Firewall rule matches
interface	Interface state changes
ipsec	IPsec/IKE negotiation
manager	Queue manager
ntp	NTP synchronization
ospf	OSPF routing protocol
packet	Packet-level events
ppp	PPP connections (PPPoE, L2TP, etc.)
raw	Raw packet events
script	Script execution
snmp	SNMP activity
system	Core system events
telephony	VoIP/telephony events
ups	UPS device events
web-proxy	Web proxy events
wireless	Wi-Fi client associations and auth

Topic Combinations in Rules

Rules use a comma-separated topic list with optional ! negation. A message must match all listed topics to be selected:

Rule topics= value	Selects
system	All system messages regardless of severity
firewall,error	Firewall messages at error severity
firewall,!debug	Firewall messages excluding debug
!debug	All messages except debug-level
critical	All critical-severity messages from any subsystem
info	All informational messages

Log Rules

Rules determine which messages each action receives. Configure rules under /system logging.

Sub-menu path: /system logging

Rule Properties

Property	Description
topics	Comma-separated topic list; supports ! negation
action	Name of the configured action to receive matching messages
prefix	Optional string prepended to each matching message
disabled	Disable the rule without removing it

Rules are evaluated in order. A message can match multiple rules and be sent to multiple actions simultaneously.

Default Rules

RouterOS ships with default rules that forward info, warning, error, and critical topics to the built-in memory action:

# View current rules
/system logging print

These defaults are sufficient for basic operation. Add custom rules to route specific topics to additional destinations (disk, remote syslog, email).

Log Actions

Actions define where matched log messages are sent. Configure actions under /system logging action.

Sub-menu path: /system logging action

Action Types

Type	Description
memory	Store in RAM ring buffer (default)
disk	Write to persistent files on storage
remote	Send to remote syslog server (UDP/TCP)
echo	Print to console (useful during live troubleshooting)
email	Send by email via the configured mail tool

Memory Action Properties

Property	Default	Description
name	—	Action name
target	memory	Must be memory
memory-lines	1000	Maximum number of lines stored in RAM
memory-stop-on-full	no	If yes, stop logging when buffer is full instead of overwriting

When memory-stop-on-full=no (the default), the oldest entries are overwritten as new messages arrive (ring buffer behavior). Setting memory-stop-on-full=yes causes logging to halt once the buffer reaches its limit, preserving the oldest entries.

Disk Action Properties

Property	Default	Description
name	—	Action name
target	—	Must be disk
disk-file-name	log	Base path and filename for log files
disk-lines-per-file	100	Lines per log file before rotating to a new file
disk-file-count	2	Number of rotated files to retain (oldest are deleted)
disk-stop-on-full	no	Stop logging when storage is full instead of rotating

Note: RouterOS does not create missing directories automatically. If disk-file-name includes a path (e.g. log/router), create the directory on router storage before enabling disk logging.

Remote (Syslog) Action Properties

Property	Default	Description
name	—	Action name
target	—	Must be remote
remote	—	IP address of the syslog server
remote-port	514	UDP/TCP port on the syslog server
remote-protocol	udp	Transport: udp or tcp
remote-log-format	syslog	Message format: syslog (RFC 3164), bsd-syslog, or cef
syslog-facility	daemon	Syslog facility code sent with messages
syslog-severity	auto	Override severity in syslog header; auto maps from topic
syslog-time-format	bsd-syslog	Timestamp format in syslog messages
cef-event-delimiter	\n	Delimiter between CEF events (only applies when remote-log-format=cef)

Common syslog facility values:

Facility	Description
kernel	Kernel messages
user	User-level messages
daemon	System daemons (default)
auth	Security/authentication messages
local0–local7	Locally defined facilities (commonly used for network devices)

Email Action Properties

Property	Default	Description
name	—	Action name
target	—	Must be email
email-to	—	Recipient address
email-from	—	Sender address (overrides tool default)

Email delivery requires /tool e-mail to be configured with an SMTP server. Each matching log message generates a separate email — use targeted topics= filters (e.g. critical) to avoid excessive email volume.

Configuration Examples

View Current Logging Configuration

# Show all active rules
/system logging print

# Show all configured actions
/system logging action print

# View the in-memory log buffer
/log print

# Follow live output
/log print follow

Custom Memory Buffer

Store more lines in RAM for extended in-session visibility, or create dedicated buffers per subsystem:

# Larger shared buffer
/system logging action add name=mem-large target=memory memory-lines=5000
/system logging add topics=system,info action=mem-large prefix="SYS "

# Dedicated per-subsystem buffers
/system logging action add name=buf-dhcp     target=memory memory-lines=500
/system logging action add name=buf-wireless target=memory memory-lines=1000
/system logging action add name=buf-firewall target=memory memory-lines=2000

/system logging add topics=dhcp     action=buf-dhcp     prefix=DHCP
/system logging add topics=wireless action=buf-wireless prefix=WLAN
/system logging add topics=firewall action=buf-firewall prefix=FW

Persistent Disk Logging

Write error and critical messages to disk, keeping 10 rotated files of 1000 lines each:

/system logging action add name=disk-main target=disk \
    disk-file-name=log/routerlog \
    disk-lines-per-file=1000 \
    disk-file-count=10 \
    disk-stop-on-full=no

/system logging add topics=error    action=disk-main prefix="ERR "
/system logging add topics=critical action=disk-main prefix="CRIT "

Email Alerts for Critical Events

Send critical messages by email. Configure the mail tool first:

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

/system logging action add name=mail-critical target=email \
    email-to[email protected]

/system logging add topics=critical action=mail-critical

Remote Syslog Server

Send log messages to a remote syslog collector over UDP port 514:

# 1. Create the remote action
/system logging action add name=rsyslog target=remote \
    remote=192.0.2.10 \
    remote-port=514 \
    remote-protocol=udp \
    remote-log-format=syslog \
    syslog-facility=local0 \
    syslog-severity=auto

# 2. Add rules to route messages to that action
/system logging add topics=info     action=rsyslog
/system logging add topics=warning  action=rsyslog
/system logging add topics=error    action=rsyslog
/system logging add topics=critical action=rsyslog

Important: Creating the action alone is not enough. You must also add at least one rule referencing the action — otherwise no messages are forwarded.

Filtering Specific Subsystems

Log firewall events (excluding debug noise) to disk:

/system logging add topics=firewall,!debug action=disk-main

Log all PPP connection events to remote syslog:

/system logging add topics=ppp,!debug action=rsyslog

Log all authentication events regardless of severity:

/system logging add topics=account action=rsyslog prefix="AUTH "

Sending to Multiple Destinations

A single message can be sent to multiple actions by matching multiple rules:

# Send errors to both disk and remote syslog
/system logging add topics=error action=disk-main
/system logging add topics=error action=rsyslog

Complete Security Logging Setup

Local disk retention combined with real-time remote syslog:

# 1. Disk action for local retention
/system logging action add \
    name=sec-disk \
    target=disk \
    disk-file-name=log/security \
    disk-lines-per-file=2000 \
    disk-file-count=10

# 2. Remote syslog action
/system logging action add \
    name=sec-remote \
    target=remote \
    remote=10.0.0.50 \
    remote-port=514 \
    remote-protocol=udp \
    syslog-facility=local0

# 3. Log security topics to both destinations
/system logging add topics=account  action=sec-disk   prefix=AUTH
/system logging add topics=firewall action=sec-disk   prefix=FW
/system logging add topics=critical action=sec-disk   prefix=CRIT
/system logging add topics=error    action=sec-disk   prefix=ERR

/system logging add topics=account  action=sec-remote prefix=AUTH
/system logging add topics=firewall action=sec-remote prefix=FW
/system logging add topics=critical action=sec-remote prefix=CRIT
/system logging add topics=error    action=sec-remote prefix=ERR

Verifying Remote Syslog Delivery

Generate a test message to confirm the remote syslog pipeline is working:

/log warning "test: verifying remote syslog delivery"

Check your syslog collector for the message. If it does not arrive:

1. Confirm the remote action has the correct IP and port.
2. Verify at least one rule references the remote action for the topics you expect.
3. Check firewall rules — UDP 514 (or TCP 514) must be permitted outbound from the router.
4. Use /log print to confirm the test message was generated locally.

Alert-Based Scripts

RouterOS has no built-in “run script when a log message matches” action. Alerts are implemented using two complementary patterns: scheduled log polling and event-driven tools like Netwatch.

Scheduled Log Polling

A /system scheduler job runs a script at a regular interval. The script uses /log find to query recent log entries and takes action when a condition is met.

# Script: check for authentication failures in the last 5 minutes
/system script add name=check-auth-failures source={
    :local entries [/log find where topics~"account" and message~"login failure"];
    :if ([:len $entries] > 0) do={
        :local count [:len $entries];
        /tool e-mail send \
            to="[email protected]" \
            subject="Router: $count auth failure(s) detected" \
            body="Authentication failures logged. Review /log on the router.";
    }
}

# Run every 5 minutes
/system scheduler add name=poll-auth-failures interval=5m on-event=check-auth-failures

# Script: alert on any critical log entry
/system script add name=check-critical source={
    :local hits [/log find where topics~"critical"];
    :if ([:len $hits] > 0) do={
        :log warning "ALERT: critical log entries detected (count: [:len $hits])";
        /tool e-mail send to="[email protected]" \
            subject="Router CRITICAL alert" \
            body="Critical log entries found. Check /log print where topics~\"critical\" on the router.";
    }
}
/system scheduler add name=poll-critical interval=2m on-event=check-critical

Tip: Use a shorter interval for high-priority conditions, but avoid intervals under 30 seconds on low-memory devices. For persistent tracking, write a state variable to a file or global variable to avoid re-alerting on the same entry.

Deduplication with a State Variable

Without deduplication, a polling script re-alerts on the same log entry every interval. Track the last processed entry time to avoid this:

/system script add name=check-critical-dedup source={
    :global lastAlertTime;
    :if ([:len $lastAlertTime] = 0) do={ :set lastAlertTime "jan/01/1970 00:00:00" };

    :local hits [/log find where topics~"critical" and time > $lastAlertTime];
    :if ([:len $hits] > 0) do={
        :set lastAlertTime [/log get ($hits->0) time];
        /tool e-mail send to="[email protected]" \
            subject="Router CRITICAL alert" \
            body="New critical log entries detected.";
    }
}

Note: Global variables are lost on reboot. For persistent state, write the timestamp to a file on disk storage.

Event-Driven Alerting with Netwatch

For connectivity and reachability events, Netwatch is more efficient than log polling — it runs scripts directly on state transitions without polling overhead:

/tool netwatch add host=203.0.113.1 interval=30s \
    down-script={
        /log error "WAN gateway unreachable";
        /tool e-mail send to="[email protected]" \
            subject="WAN DOWN" body="Gateway 203.0.113.1 is unreachable.";
    } \
    up-script={
        /log info "WAN gateway restored";
        /tool e-mail send to="[email protected]" \
            subject="WAN restored" body="Gateway 203.0.113.1 is back online.";
    }

Using /tool fetch for Webhook Alerts

Send alerts to webhook endpoints (Slack, PagerDuty, custom APIs) using /tool fetch:

/system script add name=webhook-alert source={
    :local hits [/log find where topics~"critical"];
    :if ([:len $hits] > 0) do={
        /tool fetch url="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" \
            http-method=post \
            http-content-type="application/json" \
            http-data="{\"text\":\"RouterOS CRITICAL alert detected\"}" \
            output=none;
    }
}

Prerequisite: The router must have DNS resolution and outbound HTTPS access to the webhook endpoint. Configure /ip dns and ensure the firewall permits outbound TCP 443 from the router itself.

---

External Log Management Integration

RouterOS forwards logs to external systems via remote syslog actions. The router-side configuration is the same regardless of the downstream platform — only the destination IP, port, and format vary.

Supported Output Formats

The remote-log-format property on a remote action controls the wire format:

Format	Best for
syslog	Generic syslog collectors, Graylog, Splunk, Loki
bsd-syslog	Older syslog daemons (rsyslog, syslog-ng) expecting BSD-style timestamps
cef	SIEMs that consume Common Event Format (ArcSight, QRadar, Splunk HEC)

Generic SIEM / Log Collector

This template works for Graylog, Splunk (UDP syslog input), Loki (via syslog receiver), and most other collectors:

# Remote action pointing at your log collector
/system logging action add \
    name=siem \
    target=remote \
    remote=192.0.2.50 \
    remote-port=514 \
    remote-protocol=udp \
    remote-log-format=syslog \
    syslog-facility=local0 \
    syslog-severity=auto

# Forward all severity topics — tune per your retention needs
/system logging add topics=info     action=siem
/system logging add topics=warning  action=siem
/system logging add topics=error    action=siem
/system logging add topics=critical action=siem

# Optional: forward specific high-interest subsystems
/system logging add topics=firewall,!debug action=siem prefix="FW"
/system logging add topics=account         action=siem prefix="AUTH"

Use remote-protocol=tcp if your collector requires guaranteed delivery or if messages are large.

CEF Format for SIEMs

CEF (Common Event Format) is a structured syslog extension used by SIEMs that parse events into fields. RouterOS natively generates CEF output when remote-log-format=cef:

/system logging action add \
    name=siem-cef \
    target=remote \
    remote=192.0.2.50 \
    remote-port=514 \
    remote-protocol=udp \
    remote-log-format=cef \
    syslog-facility=local0

/system logging add topics=firewall action=siem-cef
/system logging add topics=account  action=siem-cef
/system logging add topics=error    action=siem-cef
/system logging add topics=critical action=siem-cef

MikroTik provides a dedicated guide for CEF ingestion into Elasticsearch — see CEF with Elasticsearch.

Graylog

Graylog accepts syslog over UDP or TCP. Create a UDP Syslog Input in Graylog (System → Inputs), then point RouterOS at it:

/system logging action add \
    name=graylog \
    target=remote \
    remote=192.0.2.60 \
    remote-port=5140 \
    remote-protocol=udp \
    remote-log-format=syslog \
    syslog-facility=local0

/system logging add topics=info     action=graylog
/system logging add topics=warning  action=graylog
/system logging add topics=error    action=graylog
/system logging add topics=critical action=graylog

Graylog auto-parses RFC 3164 syslog. Use extractors or pipelines in Graylog to split the message field into structured fields (e.g., topic, source IP).

Splunk

Configure a UDP Data Input in Splunk (Settings → Data Inputs → UDP) on a chosen port, then:

/system logging action add \
    name=splunk \
    target=remote \
    remote=192.0.2.70 \
    remote-port=5000 \
    remote-protocol=udp \
    remote-log-format=syslog \
    syslog-facility=local0

/system logging add topics=info     action=splunk
/system logging add topics=warning  action=splunk
/system logging add topics=error    action=splunk
/system logging add topics=critical action=splunk

In Splunk, set the sourcetype to syslog or create a custom sourcetype with props/transforms to extract RouterOS topic tags.

Loki / Grafana

Loki ingests syslog via the Promtail agent or Grafana Alloy (with a loki.source.syslog component). Run Promtail/Alloy on a host that receives RouterOS syslog traffic, then forward from there to Loki.

Example Promtail syslog scrape config (on the intermediate host):

scrape_configs:
  - job_name: mikrotik
    syslog:
      listen_address: "0.0.0.0:514"
      label_structured_data: true
      labels:
        job: mikrotik
    relabel_configs:
      - source_labels: [__syslog_message_hostname]
        target_label: host
      - source_labels: [__syslog_message_app_name]
        target_label: app

RouterOS configuration (pointing at the Promtail/Alloy host):

/system logging action add \
    name=loki \
    target=remote \
    remote=192.0.2.80 \
    remote-port=514 \
    remote-protocol=udp \
    remote-log-format=syslog \
    syslog-facility=local0

/system logging add topics=info     action=loki
/system logging add topics=warning  action=loki
/system logging add topics=error    action=loki
/system logging add topics=critical action=loki

Topic Tuning for External Systems

Sending all topics at info and above can generate significant volume on busy routers. Use topic-specific rules to control what the downstream system receives:

# High-volume topics — send only warning and above
/system logging add topics=dhcp,warning  action=siem
/system logging add topics=ppp,warning   action=siem

# Security-relevant topics — send everything (no debug)
/system logging add topics=account,!debug  action=siem
/system logging add topics=firewall,!debug action=siem
/system logging add topics=ipsec,!debug    action=siem

# Always send critical from any subsystem
/system logging add topics=critical action=siem

Note: RouterOS evaluates all matching rules, so a critical firewall message matching both firewall,!debug and critical rules will be sent twice. This is usually acceptable; add a deduplication step in the SIEM if needed.

---

See Also

• Syslog with Elasticsearch — Centralized log analysis using the Elastic Stack
• CEF with Elasticsearch — Structured CEF log ingestion for SIEMs
• Netwatch — Monitor host availability and trigger scripts on state changes
• The Dude — Network monitoring and graphing
• Health Monitoring — Hardware sensor data (temperature, voltage, fan)