You Found the ERROR. The Cause Is in the Lines Before It

A real incident investigation starts the moment you find the ERROR line. The ERROR is the result — the cause is usually upstream. The WARN just above it, a timeout a few seconds earlier, a config load hundreds of lines back. If you can't see those, your report says "an error occurred" and nothing more.

Where grep's context flags stop helping

grep -B 20 -A 5 is a fine first step. Then:

• The context width is a guess made in advance. If 20 lines wasn't enough, run it again
• The extracted fragment is a different text — there's no way back to the original position when you want to go 2,000 more lines upstream
• With thousands of hits, you're now investigating your fragments instead of your log

What the job actually needs: a hit list and the original file, side by side, staying in sync.

A live demo: 4.5 billion lines → one coffee shop, in 3 steps

To show what drill-down search feels like, here's a real run — not on a log, but on something bigger: the entire US OpenStreetMap expanded to one XML file (258 GB, 4,509,830,821 lines), opened directly from its compressed .uwvz archive without unpacking.

1. New York → 100,492 hits in 30.28 s
2. Drill down: Central Park → 226 hits
3. Drill down again: coffee_shop → 3 hits

Hit #1 lands on a Starbucks at Central Park South — opening hours, address, payment methods, latitude/longitude, all in the raw tags, with ±12 lines of context shown around the hit. A right-click shows History (drill-down path): the exact three steps that got you there, each with its line number.

Swap the words and this is exactly an incident investigation: ERROR → payment service → one request ID. From millions of lines to the one thread that matters, and the path is recorded.

There are two multi-stage modes, and the difference matters for logs. Drill-down narrows within the previous hits (100,492 → 226 → 3 above). Sequence finds the terms in order of appearance in the file — same three words gave 100,492 → 2,798 → 1,246 chains, each linking occurrences thousands of lines apart. On a map file that's a curiosity; on a log it's exactly how you trace causality: deploy finished → timeout → ERROR, in that order, however far apart the lines are.

The workflow (free)

In UwView, search results open in an independent popup window:

1. Open the log (multi-GB is fine — readable the moment it opens), search ERROR
2. Double-click a hit → the main view jumps to that line and highlights it. The popup stays open, so you bounce list → scene → list as often as you need
3. At the scene, just scroll upward. 20 lines or 20,000 — the context never gets cut off, because you're in the original file
4. In the popup, turn on ±1-line context to skim every hit with the line before it. If the same WARN precedes every ERROR, you'll see it here
5. Found a suspect? Search again for the request ID / thread ID and follow that one thread through time
6. Save… writes the hits (optionally with surrounding lines) to a file — ready to attach to the report

Add color rules (ERROR red, WARN yellow) and the pattern "yellow gets denser before the accident" becomes visible while scrolling.

Free vs Pro, honestly

The whole investigation above is covered by the free edition — jump, save, and ±1-line context included.

UwView Pro (v1.3.0+) raises three ceilings for repeat work: context up to ±64 lines, an independent popup per tab (line up an app log and a DB log, cross-check their ERROR lists), and instant reopen from a saved index (~0.02–0.07 s measured). One investigation: free is enough. Returning to the same logs daily: that's Pro territory.

Full article: tracing context in a huge log. Source: GitHub.