Big Log Explorer Reference

JSON Lines (JSONL) Log Format

JSON Lines stores one JSON object per line. Each line is a complete, self-contained JSON value terminated by a newline, so a log file becomes a stream of independent records rather than one enormous array. The format travels under several names: JSON Lines, newline-delimited JSON, and NDJSON all describe the same structure.¹ Structured loggers adopted it because every line parses on its own, which means a truncated or half-written line never breaks the records around it. Consequently, a tool can read a JSONL file record by record without holding the whole document in memory. Big Log Explorer detects any line that opens with a curly brace and parses it as JSON, pulling the timestamp, level, and message out of the fields your logger wrote. That per-line structure is exactly what powers the level pills, the text search, and the time chart across millions of lines.

What is JSONL?

Why structured loggers standardized on JSON Lines

Newline-delimited JSON solved a problem that plain-text logs never could. When every record is a typed object, a downstream tool reads a field by name instead of guessing at positions inside a free-form string. The major structured loggers all emit JSONL by default: Pino, Winston, and Bunyan in Node.js, and Logstash across the wider ecosystem.²³ Because each line stands alone, a log shipper can tail the file and forward one record at a time, and a crash mid-write corrupts at most a single line.⁴ Furthermore, appending is trivial, since there is no closing bracket to seek past before a process writes the next line and flushes.

Typing fields replaces position parsing

Consequently, a tool can read a JSONL file record by record without holding the whole document in memory. Big Log Explorer detects any line that opens with a curly brace and parses it as JSON, pulling the timestamp, level, and message out of the fields your logger wrote. That per-line structure is exactly what powers the level pills, the text search, and the time chart across millions of lines. Yet the property that makes JSONL robust also makes it verbose, because every line repeats its keys. That trade of bytes for structure is why a real production JSONL export runs to hundreds of megabytes, which is precisely the size Big Log Explorer is built to open.

How Big Log Explorer reads a JSONL line

Detection happens per line, not per file, and JSON Lines is tried first. The reader checks whether a trimmed line begins with a curly brace, and if the line then parses as valid JSON it becomes a structured record. This ordering means a file that interleaves JSONL with plain access-log lines still indexes correctly, because each line is classified on its own merits. A line that opens with a brace but fails to parse falls through to the remaining formats and, when none match, is preserved as raw text.

Which timestamp and level fields the parser reads

Field extraction follows the conventions the common loggers already use. For the timestamp, the parser takes the first present value among timestamp, time, ts, @timestamp, and datetime, accepting either an ISO 8601 string or a numeric epoch in seconds or milliseconds. For severity it reads level, severity, or lvl, then folds values such as err and fatal into a canonical set. The message comes from message, msg, or body, and falls back to the whole line when none of those keys exist. Consequently, a file produced by Pino, Winston, or a Python JSON formatter arrives in the viewer with its level pills and time chart already populated, while every custom key still travels with the record for text search.

The flexibility is what makes JSONL scale across languages and frameworks. Pino, Winston, and Bunyan in Node.js write different field names than Logstash or a Python JSON formatter, yet the parser covers all of them because it accepts either common name.² That leniency means a logging migration in one language does not break the viewer, because the timestamp, severity, and message are found regardless of which convention the logger chose.

JSON Lines versus a single JSON array

A JSON array and a JSONL file can hold the same records, yet only one of them scales to a log. A single array wraps every object in one set of brackets, so a parser must read the entire file and hold it in memory before it can return the first element.⁵ JSON Lines removes the wrapper, and each line stands alone, which lets a reader process record one while record two million is still on disk. For a multi-gigabyte log, that difference decides whether a tool can open the file at all.

Yet a JSONL file is not itself valid JSON, so you cannot hand it directly to a parser that expects a single document.⁵ Big Log Explorer sidesteps that entirely by reading the file as a stream of lines in a Web Worker, parsing each one independently and writing the result to IndexedDB. Because the array-versus-stream distinction is exactly why editors choke on large arrays, JSONL is the format you want for anything you expect to grow.

Reading nested JSON fields in the viewer

Structured logs often nest data several levels deep, and JSONL carries that nesting intact on each line. A request log might embed one object for the HTTP request, another for the response, and an array of timing spans, all inside a single line. Big Log Explorer keeps the full raw line so nothing is lost, and it surfaces the top-level timestamp, level, and message for sorting and filtering. The complete JSON stays visible in the viewer row, so you can read the nested detail without opening a separate parser.

Clustering noisy JSON messages

The Patterns panel is where nested JSON logs become manageable. Each message is normalized by replacing variable parts, so two lines that differ only by a request ID, an IP, or a latency number collapse into one template. For JSON logs this matters because the same event repeats thousands of times with different values, and the raw text hides how dominant a single event really is. Consequently, a panel row reading connection reset by peer with a count of forty thousand tells you more than any amount of scrolling. Furthermore, clicking Filter on that row narrows the viewer to matching lines and combines with the level pill and time window, so you can isolate one recurring JSON event inside a five-minute spike without writing a query.

Try in the tool

Common Log Format (CLF)

The Common Log Format records one HTTP request per line. Standardized by the NCSA httpd server¹ and carried forward by Apache and Nginx², it packs the client host, the identity fields, a bracketed timestamp, the request line, the response status, and the byte count into a single fixed-order line. Every field is separated by a space, and a hyphen stands in for any value that is missing. Because the shape is rigid, a parser reads a CLF line without configuration, which is why access logs remain among the most machine-readable text formats in wide use. Big Log Explorer recognizes CLF by that shape and maps the HTTP status code straight onto a severity level, so a wall of access-log lines gains error and warning pills automatically. That mapping turns a raw access log into something you filter the same way as an application log.

What is CLF?

The seven fields of a CLF line

A CLF line packs seven fields in a fixed order⁴, and knowing them makes any access log readable at a glance. The line begins with the client host or IP, followed by the RFC 1413 identity⁵, which is almost always a hyphen, and then the authenticated user when HTTP authentication is in play. After those come the bracketed request time, the request line in double quotes holding the method, path, and protocol, the three-digit response status, and finally the size of the returned object in bytes. A hyphen appears wherever a value is unknown, so a public endpoint with no auth shows two hyphens near the front of every line.

Reading the bracketed timestamp

The timestamp sits inside square brackets in the day/month/year:hour:minute:second zone form, such as 10/Oct/2000:13:55:36 -0700. The month is a three-letter English abbreviation, and the trailing offset records the server timezone rather than UTC. Big Log Explorer parses that offset and converts each line to an absolute instant, which is what lets the time chart plot requests correctly even when servers in different zones write to the same file. Consequently, a drag-select on the chart isolates a true time window rather than a local-clock approximation.

How status codes become severity levels

Access logs carry no ERROR or WARN keyword, yet the status code already encodes severity. Big Log Explorer reads the three-digit status from each CLF line and maps it directly, so any 5xx becomes error, any 4xx becomes warn, and the 2xx and 3xx range becomes info². That single rule turns a flat access log into something the level pills can slice.

A spike of 500s during a deploy stands out in the ERROR pill without any manual tagging, and switching to WARN surfaces the 404s and 403s that often signal a broken link or a probing scanner. Conversely, a log full of 200s collapses into the info level, which keeps the noise out of your way while you hunt for failures. Because the mapping is deterministic, the same status always produces the same level, so you can trust the ERROR pill to mean server-side failures rather than a mix of guesses. That predictability is what makes access-log triage fast in the viewer.

What CLF captures and what it leaves out

For all its ubiquity, the Common Log Format captures a deliberately narrow slice of each request. It records the status and byte count but omits the response time, the referer, the user agent, and any request headers, because the original NCSA format predates the need to correlate those signals. Operators who want that context switch to the Combined Log Format, which appends the referer and user agent⁴, or to a custom format defined in the server config. The narrowness is a feature for volume, since fewer fields mean smaller lines and faster writes on a busy server.

When a line is kept as raw text

Not every access log is pure CLF. A custom log_format directive can reorder fields, add quoted strings, or drop the identity fields entirely, and such a line may not match the strict shape the parser expects. When a line fails CLF detection, Big Log Explorer does not discard it, so the line is stored as raw text, still visible in the viewer and still grouped in the Patterns panel. Furthermore, its status-derived level is simply absent, which lands the line under the other bucket rather than error or warn. You keep full search over every line even when the format drifts from the standard.

A raw-text line still has value for triage even without a parsed timestamp or status-based level. The full original text stays searchable, so keywords from an application error message or a custom field surface regardless of format. The Patterns panel still clusters that text, which means even an unrecognised line contributes to the picture of what happened during an incident. CapyToolkit's local-first design keeps every line on your machine, so nothing is stripped or normalised before it reaches the viewer, and unmatched lines stay fully exposed to search.

Clustering access logs into request shapes

A busy access log is thousands of near-identical lines, and the differences are exactly the parts you usually want to ignore. The Patterns panel normalizes each line by replacing the IP, the timestamp, numbers, and paths with placeholders, so requests to /users/1024 and /users/2048 collapse into one template. That collapse reveals which endpoints and which request shapes dominate the file, which a raw scroll can never show.

For a large access log, the top patterns often surface a single crawler hammering one path or a health check firing every second. Consequently, you can click Filter on that template to pull just those lines into the viewer, then layer a status level or a time window on top. Yet the placeholder for paths means two genuinely different endpoints can share a template when their structure matches, so the panel is a starting point for triage rather than a precise per-URL report. Read together with the status level, the pattern count tells you where a server is spending its requests.

How the time chart stays correct across timezones

A common triage mistake is to merge access logs from servers in different regions and assume the timestamps line up. The bracketed CLF timestamp carries the server local offset, so a request logged at one time in New York and one logged at the same clock time in London are not simultaneous. Big Log Explorer converts every line to an absolute instant, which is what lets the time chart show a single unified traffic curve even when the input came from servers around the world.

Try in the tool

Combined Log Format

Two quoted fields extend a standard access record with the visitor's origin and client software. Where a CLF line stops after the response size, a Combined line appends the referer and the user agent, each wrapped in double quotes.¹ Those two additions answer the questions CLF cannot: where a request came from, and which browser or bot made it.

This is the default access log on modern Nginx and the combined nickname in an Apache LogFormat directive, so most access logs you meet in production are Combined rather than plain Common.² Because the leading fields are identical, Big Log Explorer parses a Combined line exactly as it parses CLF, reading the bracketed timestamp and mapping the HTTP status to a severity level. The referer and user agent ride along in the raw line, where the text search and the Patterns panel can reach them. That combination makes Combined logs both machine-sortable and richly filterable.

What is Combined?

The two fields that Combined adds

The value of Combined Log Format lives almost entirely in its last two fields. The referer records the URL the client claims to have come from, taken from the Referer request header, which reveals whether traffic arrived from a search engine, an internal link, or a direct hit.³ The user agent records the client software string, which distinguishes a real browser from a crawler, a monitoring probe, or a scripted attack.⁴ Both fields are client-controlled and therefore never trustworthy as identity, yet in aggregate they are invaluable for understanding traffic.³⁴

For example, a sudden flood of one user agent against a login path is a classic credential-stuffing signature.⁵ Furthermore, an empty referer on requests that should carry one can hint at hotlinking or a stripped header.⁶ Because these fields are free text, they vary enormously line to line, which is precisely why the Patterns panel and a targeted text search do more with them than the eye can.⁷

Why Combined parses just like CLF here

A Combined line and a CLF line share an identical opening, and that is what the parser keys on. Big Log Explorer detects the access-log shape by matching the host, the hyphenated identity, the bracketed date, the quoted request, and the three-digit status. Those elements sit in the same positions in both formats, so a Combined line satisfies the same detection and yields the same parsed timestamp and status-derived level.⁸ The two trailing quoted fields do not interfere with detection, because the match ends at the status code.

The extra fields ride in the raw line

Detection extracts the timestamp and status, but the whole original line is always preserved, referer and user agent included. That means every character of a Combined line remains searchable in the viewer. Typing a bot name into the search box filters to lines whose user agent contains it, and searching a referring domain isolates traffic that arrived from it. Consequently, you get CLF-grade sorting and level filtering with no loss of the richer Combined context. The distinction that matters is simple: the parser reads the two fields it needs for structure, and search reads the rest.

That split is why a Combined line stays useful even when the leading fields are all you parse for structure. The referer and user agent remain in the raw text, so a later search for a campaign source or a specific crawler still finds them without re-parsing the file. Because the tool keeps the original line intact, you can move from a level filter to a free-text search in the same view without losing any of the richer context that Combined adds.

Spotting bots and referrers at scale

At the scale of a real access log, the user agent field is where bot traffic hides in plain sight. A single crawler can account for a large share of requests, and its user agent string stays nearly constant across those requests. When the Patterns panel normalizes each line, the numbers and paths collapse to placeholders while the user agent text stays largely intact, so a dominant bot often rises to the top of the pattern list as one high-count template.⁷ That surfacing is faster than any manual scan.

Conversely, human traffic fragments across many user agents and referrers, so it tends to spread thinly across the pattern list rather than clustering. Because Big Log Explorer keeps every line local in IndexedDB, you can iterate: filter to a suspicious user agent, add the WARN pill to see its 4xx responses, then drag the time chart to the window when the traffic began.⁹ Nothing in that loop touches a server, so even a sensitive access log stays on your machine.

Why the user agent stays intact during clustering

The normalizer deliberately leaves text fields like the user agent untouched while it collapses numbers and paths into placeholders. That choice is what lets a single bot stand out, because its near-constant client string survives the clustering pass while everything variable around it is blurred. CapyToolkit's local processing means the raw line is never sent anywhere, so the distinction between a bot signature and a human fingerprint stays private to your machine.

Combined logs across many servers

Production traffic rarely comes from one server, and Combined logs from a fleet are usually concatenated before analysis. Merging access logs from several web nodes into one file is routine, and it multiplies the line count into the millions quickly. Big Log Explorer is built for exactly that size, streaming the merged file in a Web Worker and indexing it into IndexedDB without loading it whole. The virtual-scroll viewer then moves through the combined log smoothly regardless of the total line count.

Keeping timezones straight

When you merge logs from servers in different regions, the bracketed timestamps carry different offsets, and a naive reader would misplace them on a shared timeline. Big Log Explorer parses the offset on every Combined line and converts each to an absolute instant, so a request logged at -0700 and one logged at +0000 sort into their true order.⁸ Consequently, the time chart shows a single coherent traffic curve across the whole fleet, and a drag-select captures the same real minutes on every node. That correctness is what makes cross-server incident triage possible without first rewriting timestamps by hand.

Try in the tool

ISO 8601 Log Timestamps

ISO 8601 removes all ambiguity from a timestamp. Standardized in its current form by ISO 8601-1:2019¹, it orders the components from most to least significant: four-digit year, month, day, then hour, minute, and second, with an optional fractional part and a timezone designator. A log line that opens with a value like 2026-07-09T14:32:05.117Z is using it.

That ordering is not cosmetic, because the fields run big-endian, so sorting the lines as plain text also sorts them chronologically, which no localized format can promise.² Application loggers standardized on it for that reason, and it is the default timestamp for Log4j, for syslog daemons configured to use it³, and for nearly every cloud log export⁴. Big Log Explorer recognizes any line beginning with an ISO 8601 date-time, reads the timestamp into an absolute instant, and treats an optional bracketed level that follows as the line severity.

What is ISO 8601?

Anatomy of an ISO 8601 timestamp

An ISO 8601 timestamp reads left to right, from the largest unit to the smallest. It begins with a four-digit year, then a two-digit month and day joined by hyphens, giving the calendar date. A separator follows, either the literal T from the standard or a space that many loggers substitute for readability³, and then the time as two-digit hour, minute, and second joined by colons. An optional fractional second, written with a dot or comma, extends the precision to milliseconds or finer.

The Z and the offset

The final component is the timezone designator, and it is what makes the timestamp absolute rather than local. A trailing Z means UTC, often read as Zulu, while a value like +02:00 or -0700 states the offset from UTC directly⁵. A timestamp with no designator is a local time whose meaning depends on the machine that wrote it. Big Log Explorer parses whichever designator is present and converts the line to a single absolute instant, so lines from different zones line up correctly on the time chart⁶. Consequently, a log that mixes UTC and offset timestamps still sorts into one true chronological order.

A timestamp with no designator at all is the one case the offset rule cannot save, because a bare local time only means something on the machine that wrote it. When a logger omits the zone, Big Log Explorer has to treat every such line as already in a single implied zone, so mixing those lines with offset-bearing ones risks a fixed skew. The practical fix is to configure the logger to emit Z or an offset, which keeps the whole file unambiguous and lets the chart plot it without guesswork.

Why big-endian order matters for logs

The ordering of ISO 8601 is the quiet reason it won. Because the year leads, then the month, then the day, a naive string sort places the timestamps in true chronological order without parsing them as dates. That property is worth more in logs than almost anywhere else, since log lines are appended in time order and read in time order.

A localized format like 07/09/2026 cannot make the same promise, because a text sort would group all the 07 values together regardless of year. Furthermore, the fixed field widths keep every timestamp the same length, so columns align and a human eye scans them quickly⁷. Yet the real payoff appears at scale, because when Big Log Explorer indexes millions of ISO-prefixed lines, the parsed instants feed a time chart that plots line counts per bucket across the whole file. A spike is then a visual event you can drag-select rather than a range you have to compute. The format that sorts cleanly also charts cleanly.

How the tool reads the level after the timestamp

After the ISO timestamp, Big Log Explorer looks for a severity marker. Many loggers write the level immediately after the time, either in brackets like [ERROR] or as a bare word such as WARN, and the parser reads either form. It then normalizes the value, folding fatal and critical into error, anything starting with warn into warn, and trace or verbose into debug. That normalization means logs from different frameworks land under the same five pills even when they spell their levels differently.

When no level is present

Not every ISO line carries a level, and the parser handles that gracefully. When no bracketed or bare severity follows the timestamp, the line defaults to info, so it still appears under a meaningful pill rather than falling into the other bucket. The full text after the timestamp becomes the message, which drives both the search box and the pattern clustering. Consequently, a plain ISO line with no explicit level is still fully usable, because it sorts on the time chart, reads in the viewer, and clusters in the Patterns panel. The only thing it lacks is a distinct error or warn classification, which you can often recover by searching the message text directly.

Sorting and charting ISO logs at scale

A large application log is usually a long run of ISO-prefixed lines, and that uniformity is exactly what makes it fast to explore. Every line yields a clean absolute instant, so the time chart at the top of the viewer stays dense and accurate across the full span of the file.

During an incident, that chart is the fastest way to see when a problem began, because a burst of error-level lines rises visibly above the baseline. Dragging across the burst filters the viewer to those minutes without any query. Because all the data lives in IndexedDB, that filtering is instantaneous even on a several-hundred-megabyte log. Furthermore, the ISO timestamp lets you combine the time window with a level pill and a text search, so you can read only the error lines mentioning one service inside a five-minute spike. The uniform, sortable timestamp is what makes each of those filters compose cleanly rather than fight one another.

Why fractional seconds help at high volume

Many ISO loggers write milliseconds or finer after the seconds field⁴, and that precision earns its keep when a service emits thousands of lines per second. Two events in the same second still sort into their true order, so a race condition or a burst of retries reads correctly rather than collapsing into one indistinguishable clump. Big Log Explorer preserves that sub-second precision when it converts each line to an absolute instant, so the time chart can bucket a dense spike without smearing events that happened milliseconds apart⁸.

Try in the tool

Syslog Format (RFC 5424)

Syslog files rarely open cleanly in a text editor. A production host can emit gigabytes of syslog a day, spanning the kernel, systemd, sshd, cron, and every service in between, and a single file quickly outgrows what an editor will load. The format itself is compact by design. Each line begins with a priority value in angle brackets that encodes both a facility and a severity, followed by a timestamp, the hostname, the process that logged it, and the message.

Two standards define the layout: the modern RFC 5424 from 2009¹ and the older BSD-style RFC 3164 that predates it². Because both pack so much into a terse line, syslog is dense and repetitive, which is where clustering and search earn their keep. Big Log Explorer opens a multi-gigabyte syslog file in the browser, keeps every line, and groups the repeats so the signal is not buried under routine chatter.

What is Syslog?

The priority value and the eight severities

Every syslog line starts with a number in angle brackets, and it encodes two things at once. It is the priority, computed as the facility multiplied by eight plus the severity. The facility identifies the source subsystem, such as the kernel, the mail system, or a local application range, while the severity states how urgent the message is. RFC 5424 defines eight severities on a fixed scale: emergency, alert, critical, error, warning, notice, informational, and debug, numbered 0 through 7. A priority of 34, for example, decodes to facility 4 and severity 2, meaning a critical authentication message.

Because the scale is standardized, tooling across every Unix-like system agrees on what a severity means. The numeric encoding keeps the header tiny, which matters when a busy host writes thousands of lines per second. Reading the priority is the key to a raw syslog stream, since it tells you at a glance which subsystem spoke and how loudly.

RFC 5424 versus RFC 3164

Two syslog standards coexist, and the difference shows up in the first characters of every line. RFC 3164, the older BSD format, follows the priority with a terse timestamp of the form Oct 11 22:14:15, then the hostname and a tag, with no year and no timezone. RFC 5424, published in 2009, replaced that with a structured header: a version digit, a full RFC 3339 timestamp complete with timezone³, explicit application, process, and message identifiers, and an optional structured-data block for machine-readable key-value pairs. The newer format is unambiguous where the older one is compact.

Which shape the tool parses

Big Log Explorer keys its timestamp detection on lines that begin with an ISO 8601 date. A native syslog line does not, because the priority and version come first, so the tool keeps such lines as raw text, fully searchable and clustered but not charted. When your daemon is configured to write an ISO 8601 timestamp at the start of the line, which rsyslog offers as a high-precision file format⁴, the tool parses that timestamp and plots it. Consequently, the cleanest path to full parsing is to emit ISO-first or JSON syslog, a point the platform guides in this section return to.

The same rule works in reverse for the JSON path. When a line opens with a curly brace, the tool treats it as JSONL and reads the timestamp and severity from the object fields, so a journald export in json mode lands on the time chart without any daemon reconfiguration⁵. That means the choice between ISO-first and JSON is mostly a matter of which downstream tool you prefer, because both give the viewer a fully parsed line.

Reading raw syslog at scale

Even when the tool treats syslog lines as raw text, a huge syslog file is still highly navigable, and the Patterns panel is the reason. Each message is normalized by replacing IPs, process IDs, hex values, paths, and numbers with placeholders, so the thousands of near-identical lines a daemon emits collapse into a handful of templates. A repeated authentication failure, a cron job firing on schedule, or a service restarting in a loop rises to the top of the pattern list as a single high-count row. That surfacing is what a raw scroll can never give you.

Conversely, a genuinely rare line stays rare in the counts, which is often exactly the anomaly you are hunting. Because every line is indexed in IndexedDB, a text search across the whole file returns instantly, so searching a hostname, a process ID, or an error string narrows a gigabyte of syslog to the handful of lines that matter. Clustering plus search turns dense syslog into something you can actually read.

What the Patterns panel reveals about a host

A single misbehaving service often floods the file with one repeated message, and the panel surfaces that repetition as a single high-count row rather than thousands of separate lines. That view turns a noisy host into a short list of the few events that actually dominate, which is where most incidents hide. Because the clustering runs entirely in the browser, you can re-filter by hostname or process without sending the file anywhere.

Getting syslog into a fully parsed shape

You do not have to accept raw-text syslog if you control the daemon. Both rsyslog and syslog-ng let you define the on-disk format through a template⁴⁶, and choosing the right template gives Big Log Explorer everything it needs to parse fully. The goal is simple: put a recognizable timestamp or a JSON object at the start of each line.

JSON and ISO output templates

Two templates work best. An ISO-first format writes the RFC 3339 timestamp as the leading field, which the tool reads directly into the time chart. A JSON template wraps each event as a single object with timestamp, severity, host, and message keys, which the tool parses like any JSONL line, complete with level pills. Furthermore, the systemd journal can export to JSON with journalctl using its json output mode, producing exactly this shape from an existing system⁵. Consequently, the practical recommendation is to export or configure syslog as JSON when you plan to analyze it, then drop the result into the tool for full timestamp and severity parsing. Native syslog stays searchable and clustered, but JSON unlocks the time chart and the level pills.

Try in the tool

Nginx Access Log Format

An Nginx access log is usually too big to scroll. A busy site writes millions of request lines a day, and the answers you want, which endpoints are slow, which return errors, which client is hammering you, are spread across all of them. By default, Nginx writes those lines in the combined format from its ngx_http_log_module¹, which is Common Log Format extended with the referer and user agent². The layout is fixed and predictable, which is what makes an access log worth analyzing rather than merely storing.

Because the default uses the CLF-style fields, Big Log Explorer parses each Nginx line automatically, reading the bracketed time_local timestamp and mapping the HTTP status to a severity level. From there the level pills, the time chart, and the Patterns panel let you answer those questions without loading the file into an editor or shipping it to a log service.

What is Nginx?

The default combined format, field by field

Nginx ships with a sensible default access log, and knowing its fields makes the file readable immediately. The combined format records the remote address that made the request, a remote user when HTTP auth is present, the local time in brackets, the full request line with method and path in quotes, the numeric response status, the number of body bytes sent, and finally the referer and user agent in quotes². Each field maps to an Nginx variable, so the log is really a rendering of the request as Nginx saw it.

The log_format directive

The format is not fixed in stone. Nginx defines it with a log_format directive that names each variable, and the built-in combined format is simply one such definition. You can add fields like the request time, the upstream response time, or the host, and you can reorder or rename them. That flexibility is powerful, yet it has a consequence for parsing, because a heavily customized format may no longer match the CLF shape the tool detects. Consequently, if you plan to analyze the log in the browser, keeping the leading combined fields intact, or switching to a JSON format, keeps every line fully parsed.

Turning status codes into a triage view

The status code is the fastest lens on an access log, and Nginx logs it on every line. Big Log Explorer maps that code to a level as it indexes, so 5xx lines become error, 4xx lines become warn, and successful responses become info⁵. That mapping means the ERROR pill instantly isolates server-side failures across the whole file.

During a bad deploy, a wave of 502 or 504 lines from a failing upstream lights up the ERROR pill and spikes the time chart at the same moment. Switching to WARN then surfaces the 404s and 403s, which separates genuine broken links from probing scanners. Furthermore, dragging the time chart across the spike narrows the viewer to just those minutes, so you read the failing requests in context rather than hunting for them. Because the mapping is deterministic and needs no configuration, an Nginx access log becomes a triage surface the moment you drop it in, with no query language between you and the answer.

Nginx error logs load as raw text

Nginx keeps two logs, and they are not the same shape. The access log is the structured, CLF-derived file this page describes, but the error log is a free-form diagnostic stream that begins with a slash-separated timestamp like 2026/07/09 14:32:05, followed by a bracketed level and a message⁶. That leading format is neither ISO 8601 nor CLF, so Big Log Explorer does not extract its timestamp and keeps error-log lines as raw text.

Yet raw does not mean useless. Every error line stays visible in the viewer and clusters in the Patterns panel, so a repeated upstream timed out or connection refused rises as a high-count template. Conversely, a one-off configuration error stays rare in the counts, which helps it stand out. Searching the error log for a specific upstream, worker process, or client IP returns matches instantly, which is usually all you need from an error log during an incident.

Why the error log stays useful without a timestamp

A raw error line loses the time-chart placement, but it keeps everything else that makes triage possible. The level word in brackets still tells you whether the event was a critical or a notice, and the message text still names the failing module or upstream. Because the tool keeps every line local, you can search the error log for a worker process or a client IP and read the surrounding lines without shipping the file to a log service.

JSON access logs for full parsing

If you want the richest experience in the tool, configure Nginx to write JSON access logs. A JSON log turns each request into a single object with named keys, which removes any ambiguity about field order and lets Big Log Explorer parse the timestamp and level from the keys directly. It also makes custom fields self-describing, since request_time or upstream_addr appear by name rather than by position.

Configuring escape=json

Nginx supports this through a log_format that sets escape=json and lists each field as a JSON key-value pair, mapping variables like time_iso8601, status, request, and request_time into the object⁴. Writing the timestamp as time_iso8601 gives the tool a clean ISO 8601 value to chart, and naming a level or deriving one from the status keeps the pills meaningful. Furthermore, JSON logs sidestep the quoting headaches that free-text user agents can cause in a positional format. Consequently, for any access log you expect to analyze rather than merely archive, a JSON format is the version that gives you time-chart precision, level pills, and clean pattern clustering all at once when you open it.

A JSON format also ages better than a custom positional one. When you add a field later, you name it in the object, and the tool still parses the lines it already understood because the known keys are unchanged. That stability is why JSON access logs stay readable across Nginx version upgrades and config changes, where a reordered positional format would silently drift out of the shape the tool expects.

Try in the tool

Apache Log Format

Apache keeps two logs, and they look nothing alike. The access log records one HTTP request per line in a structured, positional format, while the error log is a free-form diagnostic stream for the server itself. That split matters the moment you open either in a tool, because only one of them carries a machine-readable request shape. Apache builds the access log from a LogFormat directive in mod_log_config, and the built-in common and combined nicknames produce the same CLF and Combined layouts that Nginx uses.¹

Consequently, Big Log Explorer parses an Apache access log automatically, reading the bracketed timestamp and mapping the status to a level. The error log is a different story, because its weekday-first timestamp does not match the formats the tool detects, so those lines load as raw text. Knowing which log you are holding tells you what to expect before you drop the file in.

What is Apache?

Access logs: the common and combined nicknames

Apache access logging is driven by named formats, and two ship built in. The common nickname renders the Common Log Format: remote host, identity, user, bracketed time, quoted request, status, and bytes. The combined nickname adds the referer and user agent as two more quoted fields, giving the Combined Log Format that most sites enable by default. Both are defined by a LogFormat directive, and a CustomLog directive then points a log file at one of them.¹

Because the leading fields are identical to what Nginx emits, an Apache access log and an Nginx access log parse the same way in Big Log Explorer, so the bracketed timestamp becomes an absolute instant and the HTTP status maps to error, warn, or info. Furthermore, a custom LogFormat can add fields like the response time in microseconds, and as long as the leading CLF fields survive, the tool still detects the line. That shared heritage is why access-log analysis looks the same across both servers.

The Apache error log is a different shape

The Apache error log does not follow the access-log format at all. Its default line opens with a bracketed timestamp in a weekday-first form, such as [Wed Jul 09 14:32:05.123456 2026], then a module and severity like [core:error], a process and thread identifier, an optional client address, and finally the message.³ It is designed for a human reading a server problem, not for a log pipeline, which is why the layout differs so sharply from the request log.

Why the timestamp is not parsed

Big Log Explorer detects timestamps that lead with an ISO 8601 date, a CLF bracket, or a numeric day-month-year bracket. The Apache error log leads with a weekday name instead, so it matches none of those, and the tool keeps each line as raw text. Yet the error log stays fully usable. Every line remains searchable in the viewer, and the Patterns panel clusters the repeats, so a recurring segfault or a flood of client denied entries surfaces as a single high-count row. Consequently, you still find the dominant error in seconds, even though the time chart stays empty for that file.

The weekday-first order is the specific thing that defeats detection. A format like [Wed Jul 09 14:32:05 2026] leads with text, so no numeric date or ISO prefix is available for the parser to anchor on. That is different from the PHP bracket, which leads with a numeric day, and the difference is why one error log charts and the other does not.⁴ The workaround is to reconfigure Apache to log errors in a date-first form, or to pipe the file through a formatter before analysis.

PHP error logs do get a timestamp

Not every error log Apache is associated with behaves the same way. PHP, which frequently runs behind Apache, writes its own error log with a different bracketed timestamp, and that one the tool does parse.⁴ A PHP error line looks like [09-Jul-2026 14:32:05 UTC] PHP Warning: followed by the message, and the leading bracket holds a numeric day, a three-letter month, and a four-digit year.⁵

The named-month bracket

Big Log Explorer includes a parser specifically for that day-month-year bracket, covering PHP error logs and similar tools that use the same convention. When it matches, the tool extracts the timestamp and plots the line on the time chart, defaulting the level to info since PHP encodes severity in the message text rather than a separate field. Consequently, a PHP error log gives you a working time chart even though an Apache core error log does not, purely because of how each writes its date. Furthermore, searching the PHP log for PHP Fatal error or a specific file path isolates the crashes, while the Patterns panel groups the recurring warnings so you can see which one dominates.

Working across both Apache logs

In practice you often need both Apache logs open during an incident, and each answers a different question. The access log tells you what clients experienced: which requests returned 500s, when the errors began, and which endpoints were affected, all through the status-to-level mapping and the time chart. The error log tells you why, whether that is the stack trace, the module that failed, or the upstream that refused a connection. Because Big Log Explorer opens each file locally and keeps them in separate sessions, you can inspect one, then load the other without anything leaving your machine.

For the access log, drag the time chart to the spike and switch to the ERROR pill to read the failing requests. For the error log, lean on search and the Patterns panel, since it loads as raw text. Together the two logs reconstruct an incident from both sides, and neither one needs to be shipped to a server to be read.

Picking which log to open first

When an incident page fires, the access log is usually the faster first stop, because the status-to-level mapping points straight at the failing requests and the time chart shows when they began. Once you have the window, the error log is where you confirm the cause, whether that is a stack trace, a refused upstream, or a worker that ran out of memory. Opening the access log first keeps the early minutes of triage focused on impact, then the error log explains it.

Try in the tool

Log Severity Levels

Every framework spells its log levels a little differently. One writes WARNING, another writes WARN; one calls the top level FATAL, another CRITICAL, another emergency. When you pull logs from several services into one file, that inconsistency turns a simple question, show me the errors, into a guessing game about which words a given service used. Log levels exist to rank messages by urgency, from noisy debug output up to fatal failures, so an operator can filter to the severity that matters.

The idea is universal even when the vocabulary is not. Big Log Explorer resolves the mismatch by normalizing every level it reads into a small, consistent set behind four pills: ERROR, WARN, INFO, and DEBUG. Consequently, a fatal from one service, a crit from another, and an err from a third all land under the same ERROR pill, and one click filters a mixed log to exactly the severities you care about.

What is Levels?

The standard severity hierarchy

Log levels form a ladder from routine detail to catastrophic failure. At the bottom sits trace, the most verbose tier, used for fine-grained step-by-step output that you enable only while debugging a specific path. Above it, debug carries developer-oriented detail, then info records normal operational events like a server starting or a request completing. Warn marks something unexpected that did not stop the operation, error marks a failure that did, and fatal or critical marks a failure severe enough to bring the process down. Reading a log is largely a matter of choosing the right rung and ignoring everything below it.

Where frameworks disagree

The ladder is universal, but the labels are not. Python logging uses WARNING and CRITICAL with numeric values in tens.⁴, while Log4j and SLF4J use WARN and add TRACE below DEBUG.⁵. Syslog abandons words entirely for numbers 0 through 7.³. Consequently, a log aggregated from a Python service, a Java service, and a syslog daemon carries three different vocabularies for the same concepts.

That divergence is precisely the problem a normalizing viewer solves, since it lets you filter by meaning rather than by whichever spelling a given emitter happened to choose. The practical cost shows up the moment logs are merged: a Python service writing WARNING, a Java service writing WARN, and a firewall writing number 4 all mean the same mid-level event, but a text search for any one spelling misses the other two. Normalizing before display collapses those three strings into a single pill. A filter for warn then returns all of them without you knowing the original spellings, which is the difference between searching text and filtering meaning.

How Big Log Explorer normalizes levels

Big Log Explorer reduces the whole vocabulary to a canonical set as it indexes each line, and the rules are deliberately forgiving. Anything that reads fatal, crit, critical, or begins with err collapses to error. Anything beginning with warn becomes warn. Plain info or information becomes info, and debug, trace, or verbose all become debug. A value that matches none of these falls into an other bucket, which is where unparsed and level-less lines land. Because the matching keys on prefixes and known synonyms, it absorbs the common spellings without a per-framework configuration.

For JSON logs, the level comes from the level, severity, or lvl field; for ISO lines, from a bracketed or bare level after the timestamp; for access logs, from the HTTP status mapping. Furthermore, this single normalization is what makes the four pills meaningful across a mixed file, because ERROR really does mean every error-class message regardless of which service emitted it. The pills filter over meaning, not over text.

Filtering a mixed log by level

The point of normalized levels is fast filtering, and the level pills deliver it directly. Clicking ERROR restricts the viewer to error-class lines across the entire file, no matter how large, because the filter runs against the indexed records in IndexedDB rather than re-scanning text. That single click is often the first move in reading an unfamiliar log, since it strips the routine info chatter and leaves the failures.

Combining level with search and time

A level filter becomes far more powerful in combination. Select ERROR, then type a service name in the search box, and the viewer shows only that service failing. Add a drag-select on the time chart, and you narrow to that service failing within a specific window. The filters compose because each one further constrains the same indexed set rather than starting over. Consequently, you can move from millions of lines to the few dozen that describe one incident in three interactions. Furthermore, the Patterns panel respects the active level, so with ERROR selected the panel shows which error templates dominate, turning a vague sense that something is wrong into a ranked list of exactly what is failing.

Lines that carry no level

Not every log line declares a level, and how a tool treats those lines shapes how much you trust the pills. In Big Log Explorer, a line whose format supplies no severity is handled by sensible defaults rather than being dropped. An ISO line with no bracketed level defaults to info, on the assumption that a bare timestamped message is an ordinary event. A raw, unrecognized line falls into the other bucket, keeping it out of the four severity pills so it never masquerades as an error or a warning.

Because the ALL pill always shows every line regardless of level, nothing is ever hidden permanently, and you can switch to ALL to confirm you are not missing an unclassified message. Conversely, when you want a clean error view, the other bucket keeps the unlabeled noise from diluting it. This handling keeps the level pills honest, since each one shows what it claims and ALL remains the complete record.

Why a default beats a guess

Giving a missing level a stable default, rather than guessing from the surrounding text, is what keeps filtering predictable. If the tool inferred severity from keywords, a line containing the word error in its message but no level could land in the wrong pill, and a filter would leak. By pinning the fallback to info for timestamped lines and other for the rest, Big Log Explorer makes the pills a reliable map of what the log actually declared.

Try in the tool