Supported log formats
Log Lens ships with five parsers. For each file it reads a sample (the first ingestion.sample_bytes, default 65536 bytes) and asks each parser, in order, whether it supports the file. The first match wins.
The five formats
| Type | Stored type | Detected when |
|---|---|---|
| Horizon (Laravel-framed) | horizon | Filename contains horizon and the sample matches the Laravel header |
| Horizon (console output) | horizon | Filename contains horizon and the sample matches either shape horizon/queue:work prints |
| nginx access | nginx_access | Filename contains access or nginx and the first line matches the combined log format |
| Laravel | laravel | Filename does not contain horizon and the first line matches the Laravel header |
| Console | console | Fallback - always matches |
Both Horizon parsers verify the framing before claiming a file, so a horizon-named log in neither shape falls through to the Console parser instead of parsing to nothing. Because Console always matches, any text file is ingestible; it is only chosen when the four specific parsers decline.
Laravel and Horizon
A Laravel entry begins with a header line and may span multiple lines:
[2026-07-25 14:03:11] production.ERROR: Something failed
#0 /app/... stack trace continues
The timestamp, environment (production), level, and message are captured. Trailing lines are appended to the body until the next header. A horizon.log written through Laravel's logging stack has exactly this framing, and is split out by filename so it carries the horizon type.
A worker log captured straight from the console instead (horizon or queue:work writing to a file, or a process manager's stdout log) has no Laravel framing and no log level at all, in one of two shapes:
[2026-08-20 03:00:02][7f3a1c2e] Failed: App\Jobs\SyncCustomer
2026-08-20 03:00:02 App\Jobs\SyncCustomer .................... 1s FAIL
Since neither shape carries a level, the verb is the level: Failed/FAIL (or an exception class where the verb would be) is an ERROR, and every other line is INFO progress. Unheaded lines — Stack trace:, #0 /app/…, the exception message — append to the event above them, so a failure keeps the trace that explains it. Both shapes store the horizon type and the horizon environment.
nginx access
Standard combined format is parsed into IP, method, path, status, bytes, referer, and user agent. The message is rendered as HTTP <status> <method> <path>.
Console and custom logs
The Console parser tries three header patterns (a bracketed [time] LEVEL: body, an ISO-timestamp-with-level line, and a bare [time] body), then falls back to treating each line as an INFO event stamped with the file's modified time. Unheaded continuation lines attach to the preceding event.
Severity mapping
Levels are uppercased and normalized:
| Raw | Stored as |
|---|---|
WARN | WARNING |
ERR, FATAL | ERROR |
TRACE | DEBUG |
| anything else / empty | itself, or INFO |
nginx has no level field, so severity is derived from the status code:
| Status | Severity |
|---|---|
>= 500 | ERROR |
400-499 | WARNING |
below 400 | INFO |
Multi-line bodies are captured up to ingestion.capture_limit (default 4 MiB); anything beyond that is truncated.