Networking · Concept · 9 min read

Syslog, the Standard Way Devices Send Their Logs

Syslog is how network devices and servers send their logs to one central collector. Here are the severity levels, the facility, the priority value, and the ports.

Written by Marko Ristic, Editor Updated Sep 17, 2026
514the default syslog port (UDP)
8severity levels, 0 emergency to 7 debug
6514the port for secured syslog over TLS
5424the RFC defining the modern message format
Short answer

Syslog is the standard way network devices and servers report events, by sending log messages over the network to a central collector.

It separates three roles: the software that generates a message, the server that stores it, and the tools that read it, so a router, a firewall and a Linux host can all log to one place in one format.

Each message carries a severity, from 0 for an emergency to 7 for debug, and a facility that says which part of the system it came from; those two numbers combine into the priority value at the front of every message. Syslog travels over UDP port 514 by default, with a secured version over TLS on port 6514, and the modern format is RFC 5424.

  • Syslog sends log messages from devices to a central collector over the network
  • It separates the message generator, the store, and the tools that read the logs
  • Each message has a severity (0 emergency to 7 debug) and a facility
  • The default transport is UDP port 514; the secured version is TLS on 6514
  • RFC 5424 defines the modern message format, replacing the older RFC 3164
On this page

What it isWhat syslog is

Syslog exists so that everything on a network can report what happened in one language, to one place.

It is a message-logging standard. Syslog allows the separation of the software that generates messages, the system that stores them, and the software that reports and analyzes them. A device does not have to know what will read its logs; it just emits them in the standard format.

It centralizes logging from everything. A network switch, a firewall, a Linux server and a hypervisor can all send their event messages to one syslog server. That central store is what turns scattered local logs into something you can search across the whole estate at once, and it is a core part of network management.

It is a feed, not an analyzer. Syslog moves and stores messages; making sense of them is a separate job. This is why a syslog server is usually the source that feeds a log analyzer or a SIEM, the same way flow records feed a traffic analyzer.

How it worksHow syslog works, and the parts of a syslog server

The short answer to what is syslog doing on the wire: it is a client and server protocol. A device or application generates a log message about an event and sends it across the network to a syslog server that listens for it. RFC 5424 names three roles:

  • The originator generates the message: a router, a firewall, a Linux daemon, an application.
  • The relay accepts messages and forwards them, which is how branch sites pass logs up to a central server.
  • The collector gathers messages for storage and analysis. This is the syslog server.

A syslog server is three parts in turn. A listener receives messages on the syslog port. A store, either flat log files or a database, keeps the log data. Filtering and management rules then decide what is kept, what is forwarded to other systems, and what raises an alert.

On Linux and Unix systems the logging daemon is usually rsyslog or syslog-ng, and the same software plays either role: client on every server, collector on the central one. Network devices need only the address of the server and a minimum severity.

It is older than most of the network. Wikipedia credits syslog to Eric Allman, who wrote it in the 1980s as part of the Sendmail project. It spread as a de facto standard long before it was written down.

RFC 3164 documented the BSD syslog protocol as it existed in August 2001, and RFC 5424 standardized it in March 2009.

Severity levelsThe severity levels

Every syslog message is tagged with how urgent it is, on a fixed scale of eight.

Zero is the worst, seven is the noisiest. The severities run from 0, Emergency, meaning the system is unusable, through Alert, Critical, Error, Warning and Notice, to 6, Informational, and 7, Debug. The counterintuitive part is that a lower number is more serious, so filtering for "severity 3 and below" shows the problems.

Most alerting keys off the low numbers. In practice, Emergency, Alert, Critical and Error, levels 0 to 3, are what page someone. Warning and Notice are watched, and Informational and Debug are usually kept for context but not alerted on, because Debug in particular can flood a collector.

The level is set by the sender. Each device decides the severity of its own messages, so the meaning of "Warning" varies a little by vendor. The scale is standard; the judgment of what counts as which level is the device's.

FacilityThe facility

Alongside severity, each message says which part of the system produced it.

Facility groups messages by source. The facility is a number from 0 to 23 that categorizes where a message came from: the kernel, the mail system, the auth system, the syslog daemon itself, and so on. It lets a collector route or filter messages by subsystem, not just by urgency.

Local0 through local7 are yours. Facilities 16 to 23 are the "local use" range, left undefined by the standard so administrators and appliances can assign them to their own applications. Many network devices default to a local facility, which is why so much gear lands on local0 or local7.

Facility plus severity is how you filter. Together the two let a rule say something precise, such as "auth messages at Error or worse," which is far more useful than filtering on either one alone.

PRI and formatThe priority value and message format

The front of every syslog message packs the facility and severity into one number, and RFC 5424 defines the rest.

The PRI is facility times eight plus severity. The priority value, or PRI, at the start of each message is computed as the facility multiplied by 8 and added to the severity. A collector reverses that arithmetic to recover both numbers, which is how it knows the message's source and urgency from the first field.

RFC 5424 is the modern format. The current syslog format, RFC 5424, defines a message with a version, a precise timestamp, the hostname, the application name, a process ID, a message ID, optional structured data, and the message text. It replaced RFC 3164, the older BSD format, which had a looser timestamp and no structured data.

Structured data made messages machine-readable. The structured-data field in RFC 5424 lets a device attach named key-value pairs to a message, so a parser can read fields reliably instead of guessing from free text. This is the part that made syslog friendlier to automated analysis.

An example syslog message

RFC 5424 gives this example of a valid message, shown here on one line and without the unprintable byte order mark:

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - 'su root' failed for lonvick on /dev/pts/8

Read it left to right. The PRI is 34, which is facility 4, the security and authorization subsystem, times 8, plus severity 2, Critical. The version is 1.

Then come the timestamp, the hostname, the application name su, a dash for an unknown process ID, the message ID ID47, a dash for no structured data, and the event text.

Transport and portsTransport and ports

How syslog travels is where the port questions come from.

UDP port 514 is the default. Classic syslog is sent over UDP to port 514, which is fast and lossy: it adds no overhead, but a dropped datagram is a lost log with no retransmission. This is the port most people mean by "the syslog port."

TCP and TLS add reliability and privacy. Syslog can also run over TCP for guaranteed delivery, and over TLS on port 6514, defined by RFC 5425, when the logs must not travel in clear text. On any network where logs cross untrusted links, the TLS form is the right default.

Classic syslog has no authentication. A collector listening on UDP 514 accepts a message from any sender, so an event can be forged and the log data cannot prove where it came from.

TLS with certificates on both ends is the fix, and it is the security argument for port 6514 beyond encryption.

The transport is separable by design. RFC 5424 defines the message and leaves the transport to companion standards, which is why the same message can go over UDP, TCP or TLS without changing its format.

UsesWhat syslog is used for

The reason to run a syslog server is that centralized messages answer questions scattered logs cannot.

Centralized logging. Pulling every device's log messages to one syslog server means one place to search when something breaks, instead of logging into each box in turn. This is the original job syslog was built for.

Security monitoring. Authentication failures, firewall denies and configuration changes all arrive as syslog messages, which is why a security team ingests the syslog feed as a primary source for detecting an attack in progress.

Compliance and audit. Many standards require that logs be collected, retained for a set period, and protected from tampering. A syslog server with reliable transport and retention is how an organization meets those audit requirements with evidence.

Alerting and monitoring. A monitoring tool watching the syslog stream can raise an alert the moment a device reports an error, turning a raw message into action instead of a line nobody reads until later.

Keeping network device logs at all. Routers, switches and firewalls hold little local storage, so their events age out fast. Forwarding syslog to a collector is often the only way their messages are kept long enough to be useful.

Syslog and SNMP

The two protocols are complementary, and most network management systems use both. SNMP is polled: a monitoring server asks a device for counters such as interface traffic and CPU load. Syslog is pushed: the device reports an event in text when it happens.

SNMP says an interface is down. The syslog messages around it usually say why.

PitfallsWhere people go wrong

Trusting UDP 514 for logs that matter. UDP syslog silently drops messages under load or loss. For audit or security logs, use TCP or TLS so a lost packet does not mean a missing record.

Reading the severity scale backwards. Lower is more severe. Alerting on "severity above 4" catches the noise and misses the emergencies. Filter for the low numbers.

Sending everything at Debug. Debug and Informational can bury a collector and the real problems with it. Set devices to log at Notice or Warning and above unless you are actively troubleshooting.

Leaving logs in clear text across the internet. Plain UDP or TCP syslog is readable on the wire. Anything leaving a trusted network should go over TLS on 6514.

Assuming every device speaks RFC 5424. Plenty of gear still emits the older RFC 3164 format. A collector has to handle both, and mixing them without a parser that understands each leaves fields misread.

SYSLOG: DEVICES TO ONE COLLECTOR, BY SEVERITYDevicesrouters, firewalls, serverslogsSyslog servercollects and storesreadsSIEM or analyzersearches and alertsSeverity: lower is more severe0Emerg1Alert2Crit3Error4Warn5Notice6Info7DebugLevels 0 to 3 page a human; 4 and 5 are watched; 6 and 7 are context kept, not paged.PRI = facility x 8 + severity. Default UDP port 514, TLS on 6514. Modern format: RFC 5424.
Devices send syslog messages to a central server, which a SIEM or analyzer reads. Severity runs 0 (emergency) to 7 (debug), lower being more severe. The PRI is facility times 8 plus severity; the default port is UDP 514, TLS on 6514.

ComparisonThe eight syslog severity levels

CriterionSeverityMeaningTypical use
0EmergencySystem is unusablePage immediately
1AlertAct immediatelyPage immediately
2CriticalCritical conditionsPage or urgent ticket
3ErrorError conditionsAlert and investigate
4WarningWarning conditionsWatch, trend it
5NoticeNormal but significantWatch
6InformationalRoutine informationKeep for context
7DebugDebug-level detailTroubleshooting only

The line most teams draw is at Error: 0 to 3 alerts a human, 4 and 5 are watched, and 6 and 7 are context kept but not paged on.

FAQFrequently asked questions

What is syslog?

A standard for sending log messages from devices and servers to a central collector over the network. It separates the software that generates a message, the system that stores it, and the tools that read it, so everything can log to one place in one format.

What port does syslog use?

UDP port 514 by default. It can also run over TCP for reliable delivery, and over TLS on port 6514 (RFC 5425) when the logs need to be encrypted in transit.

What are the syslog severity levels?

Eight levels, from 0 to 7: Emergency, Alert, Critical, Error, Warning, Notice, Informational and Debug. A lower number is more serious, so 0 is a system-down emergency and 7 is debug detail.

What is a syslog facility?

A number from 0 to 23 that says which part of the system produced a message, such as the kernel, the mail system or the auth system. Facilities 16 to 23 (local0 to local7) are left for administrators and appliances to use.

What is the syslog priority value?

The PRI at the front of each message, computed as the facility multiplied by 8 plus the severity. A collector reverses the arithmetic to recover both the facility and the severity from that single number.

What is the difference between RFC 5424 and RFC 3164?

RFC 5424 is the modern syslog format, with a precise timestamp, structured data and clear fields. RFC 3164 is the older BSD format it replaced, with a looser timestamp and no structured data. Many devices still emit the older format.

Is syslog secure?

Plain syslog over UDP or TCP travels in clear text and can be read on the wire. The secured form runs over TLS on port 6514, which encrypts the messages and is the right choice for logs crossing untrusted links.

Why do logs go missing with syslog?

Usually because they were sent over UDP, which does not retransmit dropped datagrams. Under load or packet loss, UDP syslog silently loses messages. Use TCP or TLS for logs that must not be lost.

What is a syslog server?

The central collector that receives, stores and often forwards syslog messages from many devices. It is the searchable store that scattered local logs are centralized into, and it commonly feeds a SIEM or log analyzer.

Does Windows use syslog?

Not by default. Windows uses its own Event Log, so sending Windows events to a syslog collector needs an agent or forwarder that translates them. Unix and Linux systems, and most network gear, speak syslog natively.

Should I alert on every syslog message?

No. Alert on the low severities, 0 to 3, watch Warning and Notice, and keep Informational and Debug for context without paging on them. Alerting on everything, especially Debug, buries the real problems.

What is structured data in syslog?

A field in RFC 5424 that lets a device attach named key-value pairs to a message, so a parser can read specific fields reliably instead of guessing from free text. It is what made syslog easier to analyze automatically.

How does the syslog protocol send messages?

The syslog protocol, defined in RFC 5424, sends each message as plain text with a priority, a timestamp, a hostname and the text. The traditional transport is UDP port 514, which gives no delivery guarantee. TCP, and TLS on port 6514, exist for logs that must arrive and stay private.

Read next · Tools Network Management Software, and the Three Questions It Has to Answer The tooling a syslog collector sits alongside. Open this next11 min
Also worth reading
One packet a weekA short, illustrated explainer every Tuesday. No vendor pitches, unsubscribe in one click.