Triage a Production Incident From Logs

Incident Log Triage: Turn a Giant Export Into a Root Cause

An incident starts and a giant log lands. Now you have minutes to turn hundreds of megabytes of exported log into an answer: what broke, when it started, and how far it spread. Reading top to bottom is hopeless, and a keyword grep only helps if you already know the keyword. Big Log Explorer is built for exactly this pressure. It opens the export locally in seconds, then gives you three moves that compose: the ERROR pill to isolate failures, the time chart to find when they spiked, and the Patterns panel to rank which failure dominates. Because everything runs in your browser over an indexed copy of the file¹, each move is instant and nothing sensitive is uploaded during an active incident. Consequently, you reconstruct the shape of the outage from the log itself, without waiting on a log platform to ingest it.

The first thirty seconds

Triage rewards a fixed opening sequence, because guessing wastes the minutes that matter most. Start by dropping the export into the tool and letting it index, since the progress bar tells you how far along it is. The instant indexing completes, switch to the ERROR pill. That single move strips every routine info line and leaves only the failures, which is usually where an incident lives.²

Reading the count of error lines against the total already tells you whether this is a localized blip or a widespread outage.³ Furthermore, the time chart with ERROR active shows the failure as a spike, so you learn when it began before reading any individual message. Because the tool normalizes severity across frameworks, this works even when the export mixes services that spell their levels differently.⁴ In thirty seconds you have gone from an opaque file to two facts that shape everything after: how many errors, and when they started.

Why the ERROR pill comes first

The ERROR pill leads because it removes the most noise with the least effort, which is the right trade for a clock that is running. Before any sorting or searching, you want the routine info chatter gone, and one click does that across the entire file regardless of size. Everything after, the time window, the template ranking, builds on a view that already contains only failures. That order is why the sequence is repeatable under pressure, because each step depends on the one before having stripped what you do not need.⁵

Bounding the incident in time

Once you know roughly when the failure began, the time chart lets you draw a precise boundary around it. Dragging a selection across the spike filters every panel to those minutes at once, so the viewer, the level counts, and the Patterns panel all describe the incident window rather than the whole day. That shared boundary is what keeps triage focused instead of drifting into unrelated noise from hours earlier, and incident log triage from a local log keeps the export on your machine when the data is too sensitive to upload.⁶

Reading the shape of the spike

The spike itself carries information before you read a line. A sharp vertical cliff that starts at a single instant points to a discrete cause, whether a deploy, a config push, or a dependency going down. A gradual ramp points to something accumulating, such as a memory leak, a filling queue, or growing latency tipping requests into timeouts.⁷ Consequently, the shape narrows your hypothesis before you open a message. Furthermore, comparing the error spike against overall volume tells you whether traffic caused the failure or the failure suppressed traffic, since a spike in errors alongside a drop in total lines often means the service stopped serving. Reading the chart this way turns when did it happen into an early theory of why.⁸

Reading the chart alongside the error count keeps that theory honest. A spike that coincides with a known deploy time is a strong suspect, while one that appears during a quiet traffic period points at an external trigger rather than load. The chart does not prove the cause, but it narrows the field so the messages you open next are the ones most likely to name the true failure, instead of the first ones your scroll happens to reach.

Finding the dominant failure fast

With the window bounded, the remaining question is which failure is the incident and which are side effects. Scrolling the error lines rarely answers this, because the loudest failure and an incidental one look identical one line at a time. The Patterns panel, respecting the active time window and ERROR pill, resolves it by count.⁹

From symptom to a single template

Inside the incident window, the panel ranks the error templates by frequency, so the failure driving the outage sits at the top with a count that reveals its scale. Clicking Filter on that template isolates its raw lines, where a stack trace, an upstream address, or a status code usually names the root cause. Consequently, you move from a vague symptom to a specific failing component in a couple of clicks.

Furthermore, a second template rising sharply alongside the first is often the downstream consequence, a queue backing up because the primary dependency failed, which helps you distinguish the cause you must fix from the symptoms that clear on their own once it is resolved. That separation is frequently the difference between a fast recovery and chasing the wrong thread.¹⁰

When to use this

Use this during an active incident when you have an exported log and little time. The sequence is reliable: open and index, hit the ERROR pill, read the time chart to find and bound the spike, then use the Patterns panel to rank the dominant failure. Because the file stays local, you can work a sensitive production export in the browser without routing it through a log platform first.

Examples

Reading the file top to bottom in a terminal

Index it, hit ERROR, and note the error count versus the total

Guessing the time range from memory

Drag the ERROR spike on the time chart to filter every panel to that window

Many error types, unclear which is root cause

Rank templates in the Patterns panel within the window; the top one is the driver