GUIDE — 2026-09-13

MikroTik RouterOS syslog to a server: complete setup

RouterOS logs to memory by default, keeps a few hundred lines, and loses all of it on reboot. On a hAP or a CRS that is minutes of history, and the reboot you are investigating is exactly the event that erased the evidence. Forwarding to a machine you control is a five-line change.

Which machine receives the logs? SyslogWatch is the same application on macOS, Windows 10/11, Windows Server 2016 or newer, and 64-bit Linux, and it listens on the same port everywhere. Most people run it on a server; on a Linux server without a desktop it runs in headless mode, with the screen in your browser. Where a command below differs by platform, all three are given.

What this covers

RouterOS 6.4x and RouterOS 7.x. The logging commands did not change between them; where something is version-specific it is marked.

Before you start — the receiver's address

The device needs somewhere to send to, and that address must not change:

• macOS — ifconfig en0 | grep inet
• Windows — ipconfig | findstr IPv4
• Linux — ip -4 addr show

Give that machine a static address or a DHCP reservation. If it moves, the device keeps sending to the old address and never tells you. Silence looks the same as "nothing happened".

Step 1 — Create a remote logging action

RouterOS separates where logs go (an action) from what goes there (a rule). Make the destination first:

/system logging action
add name=remote target=remote remote=192.0.2.10 remote-port=1514 src-address=192.0.2.1 bsd-syslog=yes

• remote-port=1514 — SyslogWatch's default. RouterOS defaults to 514.
• src-address — optional but worth setting on a router with several interfaces, so the device always appears under one address.
• bsd-syslog=yes — sends RFC 3164 format with a proper priority field. Without it some receivers show every line at the same severity.

Step 2 — Choose what to send

Now point topics at that action:

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

That covers the ordinary operational picture: interfaces, DHCP leases, logins, routing changes.

Do not add topics=debug. On RouterOS that is not a severity, it is a firehose — a busy router will produce thousands of lines a second and you will spend the afternoon working out why your receiver's disk filled. The same applies to topics=packet. If you need them, add them briefly and remove them again.

Step 3 — Add the specific things you care about

Topics can be combined, so you can send one category without turning on everything at that severity:

/system logging
add topics=dhcp action=remote
add topics=wireless action=remote
add topics=firewall action=remote

Firewall logging only produces messages for rules that have log=yes set, so this is quiet until you ask for it:

/ip firewall filter
set [find comment="drop invalid"] log=yes log-prefix="INVALID"

The prefix is worth setting. It puts a word you chose at the front of the line, which makes the rule searchable later without having to remember rule numbers.

Open the port on the receiver

Most systems drop incoming UDP by default. SyslogWatch listens on 1514 rather than the privileged port 514, so it starts without administrator rights — but the firewall still has to let the traffic in.

• macOS — the firewall asks on first launch. Click Allow.
• Windows — New-NetFirewallRule -DisplayName "SyslogWatch 1514" -Direction Inbound -LocalPort 1514 -Protocol UDP -Action Allow
• Linux — sudo ufw allow 1514/udp, or on Fedora and RHEL sudo firewall-cmd --add-port=1514/udp --permanent && sudo firewall-cmd --reload

Step 4 — Check it

Look at the action's own counters:

/system logging action print detail

Then cause something. Disabling and re-enabling an unused interface is harmless and produces two lines:

/interface ethernet
disable ether5
enable ether5

To see whether packets are leaving the router at all, RouterOS has a sniffer built in:

/tool sniffer quick port=1514

That prints matching packets as they go by; press Q to stop. If nothing scrolls, the router is not sending — check the action and the rules, not the receiver.

If nothing arrives

Work out which side is at fault before changing anything on the device. Send a syslog line to the receiver from the receiver itself:

logger -n 127.0.0.1 -P 1514 -d -p local0.err "test from the receiver"

If that line appears in SyslogWatch, the application and the port are fine and the problem is on the device or in the path — a firewall rule, a wrong address, or a VLAN that cannot reach the receiver. If it does not appear, the problem is on the receiving machine.

To see whether packets are arriving at all:

• macOS / Linux — sudo tcpdump -n -i any udp port 1514
• Windows — netstat -an | findstr 1514 shows the listener; use Wireshark to see traffic

What is worth alerting on

• Repeated failed logins — RouterOS boxes on the internet get probed constantly, and the log is where you notice a password attempt that should not be happening.
• user ... logged in from an address you do not recognise.
• Interface down and up in a tight loop — usually a cable or an SFP, occasionally a power problem.
• DHCP lease exhaustion. The message is quiet and the symptom people report is "the wifi is broken".
• Reboots. If the router restarted at 04:12, you want to know before someone tells you the internet was out.

Two things that catch people

The memory action still exists. Adding a remote action does not stop local logging, and that is fine — keep it. /log print is still the fastest way to see what just happened while you are already in the terminal.

The clock. A MikroTik with no NTP and no battery comes up in 1970, and every line it sends is stamped that way. Set it before you trust any of it:

/system ntp client
set enabled=yes servers=192.0.2.1

Getting SyslogWatch

Download SyslogWatch — free tier, no sign-up, no account, no card. macOS, Windows and Linux. Everything it receives is written to disk on that machine; nothing is sent anywhere else.