From nothing to logs on screen.

1 · Start listening

The bar across the top of the window is the server. Tick the transports you want, set their ports, choose an interface, and press Start.

• UDP — what almost every device speaks. The syslog standard is port 514.
• TCP — no message loss and no size limit. 514, or 601 by convention.
• TLS — TCP with the transport encrypted. 6514.

The application starts on 1514, 1514 and 6514 rather than the standard numbers, so a first run binds without elevation on Linux and macOS, where anything below 1024 needs privilege. Set the standard ports whenever you want them; on Unix, rather than running the whole application as root, grant the binary the one capability it needs:

sudo setcap 'cap_net_bind_service=+ep' /usr/bin/syslogstudio

Or stay on 1514 and point your devices there — nothing in syslog requires 514.

Restricting who may send

Allowed sources takes IP literals and CIDR ranges. Leave it empty to accept anything.

A UDP source address is trivially forged. This filter is hygiene — it keeps a misconfigured host out of your database — not authentication. Where senders must genuinely be authenticated, use TLS with client certificates.

Pointing devices at it

# Linux, rsyslog — add to /etc/rsyslog.conf
*.*  @192.0.2.10:514      # UDP
*.*  @@192.0.2.10:601     # TCP

# Cisco IOS
logging host 192.0.2.10 transport udp port 514
logging trap informational

# A quick test from any Unix box
logger -n 192.0.2.10 -P 1514 -d "hello from $(hostname)"

2 · Read what arrives

The viewer has two modes, switched at the bottom left. Live shows the in-memory ring buffer — the last ten thousand messages, updating as they arrive. History queries the database, page by page, and reaches as far back as your retention window.

Filter by severity, source address, hostname, application, a time range, or free text. Three search modes are available in history: substring, full-text (SQLite FTS5, so error AND disk works), and regular expression.

Click a row to see every parsed field and the raw frame it arrived as. Sort by any column, or group by severity, host, application or source.

Timestamps

The column header says which zone it is showing. By default that is your machine's; in Settings you can pin it to UTC or to a named zone, which is what you want when the devices and the reader are not in the same place.

RFC 3164 messages carry no year and no zone. They are interpreted in the configured zone, and the year is chosen as the nearest one that does not put the message implausibly far in the future — a device whose clock runs a few days ahead still lands on the right date.

Messages that bend the standard

A header that is not quite RFC 5424 or 3164 is read the way a file import reads a line: rsyslog's forwarding format with its RFC 3339 timestamp, JSON, key=value as a FortiGate sends it, Cisco IOS and ASA with their sequence numbers and mnemonics, and messages with no priority at all. The priority's severity stands unless the message declares a level in a field of its own, and the raw message is always kept.

For a device that bends it further, right-click one of its messages and choose Read this device's messages differently. A source rule says which messages it covers (addresses, hostnames, applications, a pattern on the raw text), how they are read (any of the import's formats, or a regular expression), and what to correct: the hostname, the application, the time zone or the clock, the severity, the encoding. Its latest messages are read again at every change, before and after side by side, and the rule applies as messages arrive — before the live view, the history, the alerts and the routing. Rules are kept in order in Settings › Sources, exported to a file and imported elsewhere. A rule can start from a template — a device that sends no hostname, a camera, JSON behind a syslog header, garbled accents, a clock nobody set — and its way of reading, a regular expression of your own included, can be saved as a template for the next rule or a file import. Settings › Devices lists every address messages arrive from, how much each sends and how it is read, and marks the devices that bend the RFCs or send no hostname with no rule to read them. On this computer's own networks it adds each device's MAC address and maker, read from the system's neighbor table — a device behind a router shows none, since only the router's would be known — and points out a device whose address changed or an address whose device did. A rule can name devices by MAC address too, and follow one through DHCP — on the local network only, since behind a router every device arrives with the router's MAC. The messages already stored can be read again from their raw text with the rules as they are now — from every device or from one rule's addresses, over the last day, week, month or all of it.

3 · Keep it

Persistence is a local SQLite file. In Settings you choose whether it is on, where it lives, how many days to keep and how large to let it grow. Old messages are removed in the background.

Encryption at rest

Turning on encryption asks for a password and re-writes the database encrypted with AES-256-GCM. The password opens a random key, derived with Argon2id, and that key encrypts the database and everything secret beside it. The password is not stored anywhere: forgetting it loses the history, unless you made a recovery key.

With encryption on, the application asks for the password at startup. Repeated wrong answers back off, and the lockout survives a restart — so a stolen laptop cannot be brute-forced by relaunching the application.

The recovery key

A recovery key is a file that opens the database and its backups without the password. Make it in Settings › Storage and keep it away from the computer. On the unlock screen, the key opens the database and you choose a new password.

Backups

Settings › Backups sends a copy of the database to every destination you add — a folder (another disk, a network share, an NFS export), an SFTP server, an FTPS or FTP server — every day, week or month, while messages keep arriving. Each copy is encrypted on this computer before it leaves, and opens on its own, with the password it was made under or the recovery key. A server's key or certificate is shown at the first connection and trusted from then on; plain FTP, which sends its password in the clear, has to be acknowledged. A copy can be opened in the History to be read, restored in place of the database — restoring first copies the database as it was, so it can be undone — or imported: the messages it holds and the history lacks are added, and nothing else changes. An old database file imports the same way.

4 · Notice things

An alert rule is a pattern — a substring or a regular expression — plus a severity floor and, optionally, a hostname or application to narrow it. When a message matches, the rule raises an event and, if you asked for it, a desktop notification.

The cooldown is the important field. A flapping port produces a message every few seconds; without a cooldown that becomes a few hundred notifications, and the next real alert arrives in a crowd.

5 · Send it somewhere

Routing is a pair: rules decide which messages are interesting, destinations decide where they go. Every received message is offered to the router, not only the ones that trip an alert — which is what makes relaying a whole stream possible.

Rules

A rule can match on a severity range, a facility, a hostname or application glob, a source CIDR, a substring or regular expression, and a time window that may cross midnight. An empty field is no constraint, so a rule with none matches everything — which is what a plain relay wants.

Rules run in priority order, lowest first. Stop ends the chain, so a narrow rule placed early can divert something before a broad rule sees it.

Destinations

• Syslog — UDP, TCP or TLS to another collector. With keep the original hostname the far end still attributes each line to the device that emitted it, which is what makes this a relay rather than a new source.
• Webhook — a JSON envelope with every field, or your own template sent as-is. An optional bearer token is stored write-only.
• E-mail — SMTP with STARTTLS, implicit TLS or none, authenticated or anonymous, text or HTML.

TLS and mutual TLS

For a syslog or e-mail destination the security selector chooses between verifying the far end and also presenting a certificate of your own. The CA you supply is that destination's trust anchor and may be an entirely different authority from the one signing your client certificate, or the one this application serves its own listener with.

Credentials

A token or password is write-only and bound to the destination it was given for. Moving a webhook to another host, or downgrading SMTP from STARTTLS to none, drops the stored credential rather than following it somewhere it was never meant to go.

Loops

A destination pointing back at this application's own listener is refused when you save it, and again at delivery in case the listener moved onto that port afterwards. A message that has already been relayed recently is not relayed again. And a destination being flooded with repeating content is cut off, disabled and reported, rather than quietly filling a disk.

Suppression stops a message being forwarded, never received: it is still parsed, counted, stored and shown. A false positive costs one duplicate line not reaching a second collector, not a lost log.

6 · Prove it works

The Simulator tab generates syslog traffic and sends it to destinations you choose — including this application itself. Pick a profile, a rate and a mode, and you can see the whole chain work before a single device is pointed at it.

It is also the fastest way to reproduce a problem: set a rate that matches what your network does at its worst and watch what the buffer, the database and the routing do about it.

7 · Share a screen safely

Anonymous mode — the small ghost at the bottom of the sidebar, or the switch in Settings — replaces hostnames, IP addresses, MAC addresses, e-mail addresses and user names with stable stand-ins drawn from the documentation ranges reserved for exactly this (RFC 5737 and RFC 3849).

Stable matters: the same host is always the same stand-in, so two lines from one device still obviously came from one device. The masking is display-only, so your stored data is untouched — and because it is display-only it cannot govern what the router sends, which is why each destination has its own mask identifying values switch.

8 · Keep receiving with no window

Settings › Background offers two ways, kept apart because they are for different situations.

In your session

Start SyslogStudio when I sign in starts the application hidden in the tray, under your account and with your settings; Start receiving when SyslogStudio opens starts the listeners as last saved. No administrator is needed. With an encrypted database the window asks for the password at sign-in, then returns to the tray.

As a Windows service

For a machine that must receive with nobody signed in. One administrator prompt installs a service that starts at boot under its own account (NT SERVICE\SyslogStudio), with your listeners, rules, destinations and TLS certificate copied to %ProgramData%\SyslogStudio, a firewall rule for domain and private networks, and a restart after any failure. Its database is not encrypted — nobody is there to type a password at boot — and its directory is readable by administrators only. SyslogStudio has to be installed for all users to install it.

Your history follows. Installing the service can bring the messages stored here to it. Uninstalling it brings its messages back into your own database first. Encrypting while the window drives the service makes it seal what it receives for you, and its history moves into your encrypted database.

SyslogStudio.exe service status shows its state, listeners and last error; start-up errors also go to the Application event log. On Linux and macOS, SyslogStudio --headless runs the receiver with no window under systemd or launchd.

Where things are kept

Platform	Configuration and database
Windows	%APPDATA%\SyslogStudio\
macOS	~/Library/Application Support/SyslogStudio/
Linux	~/.config/SyslogStudio/
Windows service	%ProgramData%\SyslogStudio\

config.json holds the settings, rules and destinations; logs.db the messages; sinksecrets.json the destination credentials, encrypted when at-rest encryption is on. No credential is ever written to config.json.

Longer guides live in the repository: the user guide and the TLS setup notes.