unknown & custom formats

A format nobody documented still has a timestamp in it

Logier reads log files in unknown, custom and proprietary formats without configuration. When no named parser claims a line, a heuristic parser locates the timestamp, infers the severity, and hands you back a file you can filter, search, cluster and chart.

No regex to write · no format string to supply · nothing uploaded to identify the file

Fig. 00svc-ledger.out · no parser matched

the line

<2026-03-15 10:30:00.881> {LEDGER-CORE} |E|
txn_commit failed acct=88213 reason=lock_timeout

what the fallback pulls out

time
2026-03-15 10:30:00.881
level
INFO — no severity word present
service
LEDGER-CORE
message
the whole line, unmodified

|E| is not a severity word in any vocabulary, so this line is levelled INFO rather than guessed at. The honest failure is visible instead of silent.

An in-house format with an angle-bracket timestamp and a single-letter severity marker. It belongs to no named parser, and it still resolves.
11 named parsersfirst claim wins

Detection is a walk, not a guess.

Every line is offered to the registry in order, and the first parser that says it recognises the line gets it. The format reported for the file is whichever parser ended up claiming the most lines — so a file that is mostly syslog with a hundred stray lines still reads as syslog, and those hundred lines are still parsed.

The registry ends with a parser whose recognition check always returns true. That is the whole trick: there is no branch where a line is rejected for being unrecognised, because the last parser in the chain recognises everything.

  1. Android
  2. Apache
  3. OpenSSH
  4. Proxifier
  5. Spark
  6. Zookeeper
  7. Thunderbird
  8. Windows CBS
  9. BGL
  10. Linux syslog
  11. macOS
  12. Fallback — always claims the line
no parser matchedpublished behaviour

Here is the entire fallback.

Every other tool in this category describes its unknown-format handling as something clever it would rather not detail. These are the six timestamp patterns, in the order they are tried, and the complete severity vocabulary. Read them and you know in advance whether your file will open.

  1. 01ISO 86012026-03-15T10:30:00.881ZDate and time separated by T or a space, optional milliseconds, optional Z or ±HH:MM offset.
  2. 02Classic syslogOct 25 14:32:10No year in the format at all, so the current year is assumed.
  3. 03Android-style03-15 10:30:00.881Month and day only, with milliseconds required. Current year assumed.
  4. 04Slash-separated26/03/15 10:30:00Two- or four-digit year, slashes rewritten to hyphens before parsing.
  5. 05Epoch milliseconds1773567000881Any bare 13-digit number on the line.
  6. 06Epoch seconds1773567000Any bare 10-digit number, multiplied up to milliseconds.

and the level vocabulary

FATAL
FATAL · CRITICAL · EMERG · ALERT · CRIT
ERROR
ERROR · ERR · EXCEPTION · SEVERE
WARN
WARN · WARNING · NOTICE
INFO
INFO · INFORMATION
DEBUG
DEBUG · TRACE · VERBOSE · FINE

The parser stops at the first pattern that produces a valid date. A pattern that matches but yields nonsense — a 13-digit number that isn’t a real epoch — falls through to the next rather than failing the line.

Five fields, and how honest each one is.

time
Whichever timestamp pattern matched first, as a real epoch.
rawTimestamp
The matched substring, kept verbatim so you can see what it read.
level
First level pattern found anywhere in the line. Defaults to INFO when none matches.
service
A bracketed token immediately after the timestamp — [svc], (svc), {svc} — or a Name: prefix that isn't a level word. Otherwise empty.
message
The whole line, unmodified. The fallback does not try to strip the parts it already identified.

Nobody sets out to invent a log format.

Undocumented formats are not exotic. They are the ordinary output of software that was written before anyone thought of the log as an interface.

  1. 01

    Internal tools and services

    Written years ago by an engineer who picked a line format that made sense at the time and documented it nowhere. The person who could explain it has left.

  2. 02

    Vendor appliances and black boxes

    Hardware or software you bought, emitting a diagnostic log in a shape that exists nowhere else and is not described in the manual you were given.

  3. 03

    Embedded and firmware output

    Serial console dumps and device logs, often with an unusual timestamp convention or no severity field at all.

  4. 04

    Legacy line-of-business systems

    Decade-old applications still in production, still writing the format they shipped with, still nobody's responsibility.

The usual answer is “write it yourself”.

Each of these is a reasonable tool with a real cost, and each one assumes you will read this format often enough to amortise the work.

  1. 01

    Write a regex

    Works until the format shifts — a different severity token, a wrapped stack trace, a line with no timestamp — and then silently drops the entries you needed without telling you it did.

  2. 02

    Author a Grok pattern and run a pipeline

    Reasonable for a format you will read a thousand times. Disproportionate when you need to understand one file, once, today.

  3. 03

    Supply a format string

    Assumes the format is expressible in the tool's vocabulary. Ad-hoc logs frequently are not, and you find out only after writing it.

  4. 04

    grep it and read by eye

    Viable for a few thousand lines. Hopeless past that, and it gives you no levels, no timeline, and no way to tell repetition from novelty.

the honest limit

A readable log is not a schema.

Heuristic parsing is the right answer when you need to understand a file now, or when the format is not worth a permanent investment. It is not the right answer for everything.

If you read the same proprietary format every day and depend on specific named fields — a transaction ID you want to group by, a tenant you want to filter on, a latency value you want to sort numerically — then a purpose-built parser will serve you better than a heuristic one, in Logier or anywhere else. Logier lets you describe that format once as a custom schema and keep it beside the service that writes the log. The fallback gets you a navigable file; it does not get you named fields.

faq

Common questions

keep reading

Related capabilities

  1. 01

    Automatic log format detection

    The eleven named parsers in full, each with a real sample line in its native shape.

  2. 02

    AI root cause analysis

    Ask what broke in plain English — it reasons over parsed entries, so a heuristic parse works like any other.

  3. 03

    Local-first log privacy

    Proprietary software usually means sensitive logs. Nothing is sent anywhere to identify a format.

  4. 04

    Logier vs. lnav

    lnav knows more formats out of the box. The difference is what each one does when nothing matches.

Open the file. See what it says.

No parser to write and no pipeline to stand up — including for formats nobody has ever documented.