How to send a test syslog message

A syslog routing or forwarding change is hard to trust until a message with known text, facility, priority, and tag appears in the destination that the rule should receive. A unique logger entry gives the local daemon, filters, file actions, journal bridge, and remote receiver one event to follow without waiting for a real application to produce traffic.

logger writes a one-line message to the system log path and can set the syslog priority as a facility-level pair such as local0.notice. The tag becomes the program name field that most syslog formats display before the message text, which makes it useful when a filter or dashboard searches by program name.

Commands here use a Linux host with rsyslog writing general messages to /var/log/syslog. Search /var/log/messages, journalctl, a dedicated rule file, or a remote collector instead when that is the destination under test, and treat the matching destination entry as proof because a successful logger exit alone does not prove storage or forwarding.

Steps to send a test syslog message:

Open a terminal session on the host that should generate the syslog event.
Choose a unique token, a tag, and the facility/priority pair that the target rule should see.
```
Token: sg-test-20260605
Tag: sg-test
Priority: local0.notice
```
Use local0 through local7 for application or pipeline tests when no existing facility is required. Use the same facility and priority that the filter, route, or remote forwarding rule expects.
Send the test message with logger.
```
$ logger --priority local0.notice --tag sg-test "sg-test-20260605 local syslog path"
```
--priority may also be written as -p, and --tag may also be written as -t. If no priority is supplied, logger uses user.notice.
Search the expected local syslog file for the unique token.
```
$ sudo grep "sg-test-20260605" /var/log/syslog
2026-06-05T01:42:40.244391+00:00 syslog-lab sg-test: sg-test-20260605 local syslog path
```
Use /var/log/messages on distributions that store general syslog output there. If the test is for a dedicated file rule, search that rule's file instead. Related: How to route syslog messages to a file in rsyslog
Confirm that the displayed tag and message text match the test event.

The default file format may not print the facility and priority. If the rule depends on those fields, verify the destination that uses the rule or add a temporary rsyslog template that prints syslogfacility-text and syslogseverity-text. Related: How to filter syslog messages by facility and priority in rsyslog
Search the remote receiver or filtered destination for the same token when the message is meant to prove forwarding.

Use the receiver's normal search surface, such as a collector file, SIEM query, or log viewer, and keep the token exact so it cannot be confused with an older test. Related: How to forward syslog messages with rsyslog
Troubleshoot the local path first if the message is missing everywhere.

A successful logger command does not guarantee that a downstream file, rule, or receiver stored the event. Check the local syslog service, socket path, and filtering rules before changing the forwarding target. Related: How to troubleshoot missing syslog messages