Find Errors in Log Files

How to Find Errors in Log Files Across Different Level Names

Finding the errors is the whole point. Something broke, and the log holds the evidence, but the failures are buried under thousands of routine info lines that mean nothing to your current problem. The naive approach, scrolling or grepping for the word error, misses the fatals, the crits, and the 500s that never spell it out.¹²

Big Log Explorer solves this by normalizing every severity it reads into an ERROR pill that means all error-class messages at once. One click isolates them across the entire file, whether they arrived as a JSON level field, a bracketed ISO level, or an HTTP status code from an access log. Consequently, a fatal from one service and a 502 from another appear side by side under the same filter. From that error view, the time chart and the Patterns panel tell you when the failures clustered and which ones dominate.

One pill for every error dialect

The reason grepping for error falls short is that failures do not agree on a word. A Node service might log fatal, a Python service critical, a Go service err, and an access log nothing at all beyond a 500 status.³¹ Searching one keyword catches one dialect and silently drops the rest, which is how a real failure hides in plain sight during an incident.

Fatals, crits, and 500s all count

Big Log Explorer normalizes as it indexes, folding fatal, crit, and critical and anything starting with err into a single error class, and mapping 5xx access-log statuses to the same class.³² The ERROR pill then filters on that normalized class rather than on any literal string. Consequently, clicking it once surfaces every server-side failure in the file regardless of which vocabulary produced it. Furthermore, because the normalization happens during indexing, the filter stays instant even on a large log, since it selects pre-classified records from IndexedDB rather than scanning text.⁴⁵ You get a complete error view without having to remember every synonym a given framework might have used, which is exactly what you want when something is on fire.

The class is also stable across formats, which is the part a flat text search cannot offer. A JSON app log, an ISO syslog line, and a CLF access log each express severity differently, yet after normalization they share the same error bucket, so the ERROR pill treats them as one stream. That is what makes a mixed export, where app and access lines are interleaved, sortable by failure rather than by origin.

When the errors started

Knowing which lines are errors is half the answer, and knowing when they began is the other half. The time chart plots line counts per time bucket across the whole file, and with the ERROR pill active it plots only the errors.⁶ A healthy service shows a flat, low error baseline, so a failure announces itself as a sudden vertical spike that you can see before reading a single line.⁶ That visual cue is often the fastest way to locate an incident in a long log.

Dragging across the spike filters the viewer to those minutes, so you read the errors in the window where they clustered rather than scattered through the day. Because the chart and the pill share the same indexed data, switching between them is instant.⁴ Furthermore, the shape of the spike itself is informative, since a sharp cliff suggests a deploy or a dependency dropping, while a slow ramp suggests a leak or a queue filling over time.

Pairing the chart with the Patterns panel

The chart tells you when, but the Patterns panel tells you what, and the two read best together. Once you drag across the spike to lock the time window, the panel ranks the error templates inside that window, so the failure that caused the cliff sits at the top rather than buried in the surrounding noise.⁷ That pairing turns a vague sense of when something broke into a specific, countable failure you can act on, without leaving the ERROR view.

Which error dominates

A spike of errors is rarely a single failure, but usually one dominant failure plus a scatter of unrelated noise. Reading them in order tells you little about which one matters, because a loud, frequent error and a rare, incidental one look the same line by line. The Patterns panel answers the question that raw reading cannot: which error is actually driving the incident. Catching every error severity in logs surfaces the dominant failure across services that spell it differently, because the ERROR pill folds fatal, crit, and 5xx into one filter.

Ranking errors by frequency

With the ERROR pill active, the Patterns panel clusters the error lines by normalized template and ranks them by count.⁷ The template that tops the list is, by definition, the failure happening most, and its count tells you the scale. Consequently, you move from a wall of red lines to a ranked list of distinct error types in one glance. Clicking Filter on the top template pulls just those lines into the viewer, and adding the time window confirms whether that error is the one that spiked. Furthermore, a second template rising unusually high often reveals a knock-on failure, the downstream effect of the first, which helps you separate cause from symptom without guessing. That ranking is frequently the difference between a fast recovery and chasing the wrong thread.

When to use this

Turn to this the moment a service misbehaves and you have its log. Drop your export into Big Log Explorer and click the ERROR pill first, before you read a single line, to see the full failure count regardless of which vocabulary each service used. The time chart shows when the failures started, and the Patterns panel ranks which one dominates. It works equally on application logs with textual levels and access logs where the severity is an HTTP status, so a mixed incident export stays readable.

Examples

grep -i error app.log   # misses fatal, crit, and 500s

Click the ERROR pill; every error-class line appears regardless of wording

Scrolling a day of logs to find the spike

With ERROR active, read the time chart and drag across the spike

Hundreds of red lines, unclear which matters

Open the Patterns panel to rank error templates by count