How to Configure Syslog on a Cisco Router (Step by Step)

Step 1 — Understand the severity levels (0-7)

Every syslog message carries a severity from 0 to 7. Lower is worse. The scale is fixed across all Cisco IOS platforms: 0 emergencies (system unusable), 1 alerts (immediate action needed), 2 critical, 3 errors, 4 warnings, 5 notifications (normal but significant), 6 informational, 7 debugging (verbose debug output).

The one rule that trips people up: when you set a logging threshold, you get that level plus everything MORE severe — that is, everything numerically lower. Set a destination to warnings (4) and it delivers levels 0 through 4. Set it to debugging (7) and it delivers everything the box can emit. So a higher number is more verbose, not less.

In almost every logging command you can type either the keyword (warnings) or the number (4); they are interchangeable. Keep this scale in mind for the rest of the guide — Steps 4, 5, and 6 are all just choosing a number on it for three different destinations.

Step 2 — Turn on real timestamps

By default IOS stamps each log entry with the system uptime (for example, %LINK-3-UPDOWN at 3d04h). That is useless for correlation — you cannot line up an event on R1 against an event on a firewall or a server when one is counting seconds since boot and the other has a real clock. This is the single most common reason a syslog deployment is worthless in an incident.

service timestamps log datetime msec replaces uptime with a real date and time down to the millisecond, which is the resolution you need to order events during a fast-moving fault. Add the same for debug output so live troubleshooting is stamped too.

Timestamps are only as good as the clock behind them, so synchronize the router with NTP. Optionally add localtime show-timezone so the displayed time is your local zone and unambiguous rather than raw UTC. Do this on every device you log from — consistent, synced timestamps are what make centralized logging searchable.

R1# configure terminal
R1(config)# service timestamps log datetime msec
R1(config)# service timestamps debug datetime msec
! optional: show local time and the zone label
R1(config)# service timestamps log datetime msec localtime show-timezone
! keep the clock honest so timestamps line up across devices
R1(config)# ntp server 192.0.2.123

Step 3 — Point the router at a syslog server

logging host <ip> tells the router where to send messages. By default they go over UDP port 514; TCP and non-default ports are available as options on the same command if your collector requires them. Logging is on by default (logging on), so this one line is usually all it takes to start a feed.

You can configure more than one host to fan out to multiple collectors — just repeat the command. In production, also pin the source address with logging source-interface, typically a loopback, so every message arrives with a single stable source IP no matter which physical interface it egresses. That keeps your collector's per-device views clean when links or paths change.

Reachability matters: the server must be routable from the router (and any firewall in between must permit UDP 514, or whatever port you chose). If the path is broken, messages are simply dropped over UDP — you will not get an error on the router.

R1(config)# logging host 198.51.100.10
! recommended: stable source IP for all messages
R1(config)# logging source-interface Loopback0
! a second collector is fine — just add another host
R1(config)# logging host 198.51.100.11

Step 4 — Set the severity threshold sent to the server

logging trap <level> controls how much detail leaves the router for the syslog server. The default is informational (6), which sends levels 0 through 6 — everything except raw debugging. For most production routers, notifications (5) or warnings (4) is the right balance: you capture interface flaps, protocol adjacency changes, and errors without shipping routine chatter.

Remember the include rule from Step 1. Set trap too restrictive (say critical, level 2) and genuinely useful warnings and errors never reach the server. Set it to debugging (7) and you flood the collector — and your storage — with noise that buries the events you actually care about. Pick the least verbose level that still captures what you need to investigate an outage.

You can specify the level by keyword or number; the two lines below are identical.

R1(config)# logging trap notifications
! equivalently, by number
R1(config)# logging trap 5

Step 5 — Keep an on-box buffer as a fallback

logging buffered <size> <level> keeps a rolling copy of log messages in the router's RAM. This is your safety net for when the syslog server is unreachable — the box keeps recording locally even when the network to your collector is down, which is exactly when you most need the record. It is a ring buffer, so once it fills, the oldest entries are overwritten.

The default buffer is small and its size varies by platform, so set an explicit size (in bytes) large enough to hold a meaningful window of history — a few tens of kilobytes is a reasonable starting point on a router. The level argument works the same as everywhere else; informational is a sensible buffer threshold since RAM is cheap and local.

One caveat: the buffer lives in RAM, so it does not survive a reload or power loss. It complements the syslog server, it does not replace it. View it any time with show logging and wipe it with clear logging.

R1(config)# logging buffered 32768 informational
! read the buffer
R1# show logging
! clear it (does not touch the server or the config)
R1# clear logging

Step 6 — Tune console and terminal logging

The console defaults to logging at debugging (7), meaning every message the router generates prints straight to the console line. On a busy or misbehaving box this floods the screen, and because console output is processed synchronously it can make the CLI effectively unusable — you cannot type a command during the exact event you are trying to fix. Raise the console threshold, or disable console logging entirely and rely on the buffer and server instead.

For SSH and Telnet sessions the equivalent control is logging monitor <level>, and a message will only appear in your remote session after you also run terminal monitor for that session (it is off by default and resets when you disconnect). This lets you watch live logs over SSH without permanently spamming the console line.

R1(config)# logging console warnings
! or turn console logging off entirely on a chatty box
R1(config)# no logging console
! control what a remote (SSH/Telnet) session can display
R1(config)# logging monitor informational
! then, per session, opt in to seeing them
R1# terminal monitor

Step 7 — Verify with show logging

show logging is the one command that confirms the whole configuration. The header summarizes the state of every destination: whether console, monitor, buffer, and trap logging are enabled and at what level, each configured host and whether it is active, and message counters. Below the header you see the buffered messages themselves, already stamped with the real timestamps you enabled in Step 2.

Read the header first and confirm the trap level, the buffer size and level, and that each logging host shows as active. Then prove delivery end to end: generate a harmless event — bouncing a loopback is a clean, low-risk trigger — and confirm the resulting %LINK/%LINEPROTO messages appear both in the local buffer and on your syslog server. If it shows locally but not on the server, the problem is the path or the trap level, not the logging config itself.

R1# show logging
! generate a test event and confirm it lands locally and on the server
R1(config)# interface Loopback0
R1(config-if)# shutdown
R1(config-if)# no shutdown
R1(config-if)# end
R1# show logging

Common problems (and the fix)

Logs show uptime instead of a real date, and events cannot be correlated across devices. Cause: service timestamps was never configured, so entries carry only seconds-since-boot. Fix: enable datetime timestamps and sync the clock with NTP on every logging device.

The console scrolls uncontrollably and you cannot type. Cause: console logging is at its default of debugging (7) on a device that is generating lots of messages. Fix: raise the console threshold to warnings, or disable console logging entirely and read events from the buffer and server instead.

Nothing is arriving at the syslog server. Cause: the trap threshold is too restrictive, no host is configured, or the server is not reachable over UDP 514. Fix: set logging trap to a verbose-enough level (informational is a safe default), confirm the logging host, and verify reachability and the source interface. Remember UDP drops are silent.

The server is drowning in noise and storage is filling. Cause: the trap level is set to debugging (7), shipping everything. Fix: dial logging trap back to notifications or warnings so only significant events leave the router.

Timestamps disagree between devices, so ordering events during an incident is guesswork. Cause: clocks are not synchronized. Fix: point every device at NTP, and add localtime show-timezone so the displayed time is unambiguous.

! 1) logs show uptime, not wall-clock time
R1(config)# service timestamps log datetime msec
R1(config)# ntp server 192.0.2.123
!
! 2) console flooded / CLI unusable
R1(config)# logging console warnings
!   (or) R1(config)# no logging console
!
! 3) nothing reaching the syslog server
R1(config)# logging host 198.51.100.10
R1(config)# logging trap informational
R1(config)# logging source-interface Loopback0
!
! 4) server flooded with debug noise
R1(config)# logging trap notifications
!
! 5) timestamps disagree across devices
R1(config)# service timestamps log datetime msec localtime show-timezone
R1(config)# ntp server 192.0.2.123