5 May 2026 8 min read
Every application writes logs differently. IIS uses W3C format. Veeam VBR has its own structured layout. SQL Server writes errors with a specific date prefix. Kubernetes klog has its own timestamp scheme. Syslog comes in two incompatible standards (RFC 3164 and RFC 5424) and most implementations violate at least one of them.
If you want a single tool that can load any of these and let you filter, correlate, and search across them together, you have to solve three problems: detecting which format you’re dealing with, parsing timestamps that don’t conform to any single standard, and correlating events across files that disagree about what time it is.
LogSleuth does all of this. The solutions are less elegant than I’d like and more effective than I expected.
A profile is a description of a log format: what patterns appear in the content, what the filename often looks like, and how to extract a structured LogEntry (timestamp, severity, message) from a raw line.
The 24 profiles in LogSleuth v1.1.0 cover:
The plain text profile is the catch-all. It assigns severity based on keywords (ERROR, WARN, INFO appearing anywhere in the line) and attempts timestamp extraction with the heuristic chain. It’s imprecise for unstructured logs, but it makes the file at least searchable.
When you open a file, LogSleuth scores it against each profile. The scoring has two components: content scoring (regex patterns characteristic of the format matched against a sample of lines) and a filename bonus (0.3 confidence added if the filename matches a typical pattern for that format — *.log for IIS, VBK* for Veeam, etc.).
The content scoring reads the first several hundred lines and runs each profile’s characteristic regexes against them. The profile that scores highest wins. If confidence is low — none of the profiles match well — it falls back to plain text.
This works accurately for structured formats where the line structure is distinctive. It struggles with formats that look similar to each other. A Log4j log and a Tomcat log can be nearly identical in structure, and the filename is the distinguishing factor. That’s why the filename bonus exists.
Manual override is always available. If auto-detection picks the wrong profile, you can switch it. The switch re-parses the loaded file with the new profile immediately.
This is where the interesting engineering lives.
Timestamps in log files are a disaster. Different applications use different formats. Some include timezone offsets, some don’t. Some include milliseconds, some don’t. Some formats are ambiguous (is 04/05/2026 the 4th of May or the 5th of April?). Some applications omit the year on the assumption you’re reading the log in the same calendar year it was written.
LogSleuth uses a 15-heuristic fallback chain. When the profile’s primary timestamp pattern doesn’t match, each heuristic is tried in order:
2026-05-01T14:32:11Z and variations2026-05-01 14:32:11,1232026-05-01 14:32:112026-05-01May 1 14:32:11 (no year — year injection from current year)05/01/2026 14:32:1101/05/2026 14:32:1101 May 2026 14:32:1101 May 2026 14:32:115/1/2026 2:32:11 PM20260501[01.05.2026 14:32:11]The BSD syslog case (heuristic 7) injects the current year because the format doesn’t include one. This is correct for logs written in the current year and wrong for archived logs from a previous year. There’s no good solution — if the log doesn’t tell you the year, you have to guess. Current year is the least-wrong guess.
The US vs European date format ambiguity (heuristics 8 and 9) is handled by profile: IIS uses US format, most European system logs use European format. When the profile doesn’t specify, the heuristic tries both and picks whichever produces a date that looks plausible (not in the future by more than a year, not before 2000).
The most useful feature in a multi-file viewer is seeing what was happening across all your sources at the moment something went wrong.
LogSleuth’s time correlation highlights entries within a configurable window (default ±30 seconds) of a selected entry. If you click an error in the Veeam log at 14:32:11, entries in the SQL Server log, the Veeam agent log, and the Windows event log within 30 seconds of that timestamp get highlighted. You see the cascade — what happened just before, what happened just after, across all your sources simultaneously.
The implementation relies on timestamps being comparable across files. This breaks if the sources are on different machines with unsynchronised clocks, or if one source is using UTC and another is using local time without an offset. Both are common in practice. The correlation window exists partly to absorb minor clock drift; for servers with genuinely out-of-sync clocks, you can widen the window in settings.
Log files repeat. Application restart loops generate thousands of identical “connection failed” lines. Log4j MDC threads log the same initialisation block on every service start. Reading through these manually is painful.
LogSleuth has three deduplication modes:
Off. Every line appears. The raw view.
Exact. Consecutive identical lines are collapsed into one with a count. “Connection failed (×47)”. Simple and effective for literal repetition.
Normalized. Before comparing, a regex substitution replaces variable components — GUIDs, IP addresses, hexadecimal values, numeric IDs — with placeholders. Two lines that differ only by a request ID or a timestamp are treated as the same for deduplication purposes.
Normalized mode is the useful one for application logs. Exact mode is better for system logs where the variable components are part of the semantic content (you do want to see each different IP that caused a “connection refused”).
For tailing active logs — a service you’re actively debugging, a process you’re monitoring — LogSleuth polls the file every 500ms and appends new entries to the view. The view auto-scrolls to the newest entry unless you’ve scrolled up, in which case it stays where you are.
Directory watch is broader: point it at a directory and it monitors for new files (polling every 2 seconds) and for changes to existing files. This is useful for log directories where the application rotates logs on a schedule — new files appear automatically.
Log rotation for LogSleuth’s own internal log happens at 5 MB stored in %LOCALAPPDATA%\LogSleuth\logs\. The tool logs its own parse errors and profile detection decisions there, which is useful when auto-detection makes an unexpected choice and you want to understand why.
The filter panel has six independent controls that compose with AND:
4000-4999) and negation (!1001) for Windows Event Log profilesFuzzy matching uses edit distance, which is useful for log entries where the exact phrasing varies slightly between versions of the application. Regex mode hands the search string directly to the regex crate — it doesn’t sanitise the input, so if you put an invalid regex in the box it’ll show an error and clear the results until you fix it.
Filtered results export to CSV or JSON. The CSV export includes all columns; the JSON export produces an array of LogEntry objects with the parsed fields.
Session state — which files are loaded, what filters are active, which entries are bookmarked, the correlation window setting, the current profile selections — persists across closes. The state is stored as TOML in %APPDATA%\LogSleuth\session.toml. On next launch, the session restores automatically. This is useful for ongoing investigations where you close the tool at the end of the day and pick up where you left off.
Bookmarks are gold-highlighted entries. They survive session save/restore. There’s no annotation feature — if you need to explain why something is bookmarked, that goes in a separate note-taking tool.
LogSleuth is on GitHub, MIT licensed. It runs on Windows, macOS, and Linux.