How to Search Log Files Effectively: grep, Find and Filters

A log file with a hundred thousand lines contains the answer to your problem on one or two of them. Searching well is a skill, and it comes down to asking narrow questions in a sensible order.

Work out what to search for

Before typing, decide what you know:

• A time. When did the user notice the problem? Even an hour's window helps.
• A severity. Failures are usually ERROR or FATAL; early symptoms are WARN.
• An identifier. A request ID, order number, user name, device ID or filename that appears in the failing action.
• A message fragment. Text from an error dialog or notification.
• A component name. The module or service involved.

Search in an editor

In any editor or browser tool, the Find box does a plain-text search. In Docento's Text & Markdown Editor, open the .log file, choose Find, type a term such as ERROR, and the match count appears with buttons to step through each one. Search is case-insensitive. It suits files up to 5 MB.

Tips for editor searches:

• Search for the most distinctive string first, such as an exception name rather than the word "error".
• Step from the top to find the first occurrence, since the first failure usually matters most.
• Search for the ID to find every line belonging to one request.

Search with grep

On Linux and macOS (and Windows with WSL or Git Bash), grep is the workhorse:

• grep "ERROR" app.log shows lines containing ERROR.
• grep -i "timeout" app.log ignores case.
• grep -n "ERROR" app.log adds line numbers, useful for jumping to a spot in an editor.
• grep -C 5 "ERROR" app.log prints five lines of context before and after each match.
• grep -B 10 "Exception" app.log prints ten lines before, which is often where the cause is.
• grep -v "health check" app.log excludes lines you do not care about.
• grep -c "ERROR" app.log counts matches.
• grep -E "ERROR|FATAL" app.log matches either word, using extended regular expressions.
• grep -r "request-8841" /var/log/myapp/ searches every file in a folder.

PowerShell users have Select-String, for example Select-String -Path app.log -Pattern "ERROR" -Context 3,3.

Combine filters

Pipe results through further filters to narrow progressively:

grep "2026-10-02 14:" app.log | grep ERROR | grep -v "retry"

That reads: lines from 2 pm on that date, only errors, excluding retry noise. Build the command one step at a time and check each stage's output.

Search by time range

Many logs start each line with a sortable timestamp, so a prefix match selects a window. grep "^2026-10-02 14:3" app.log selects the minutes from 14:30 to 14:39. Be careful with time zones: servers often log in UTC.

Follow one request through the log

Find the request or correlation ID in an error line, then search for that ID. You get the full story of that request, across components, in order. Structured logs, where each line is JSON, are especially easy to filter by field with tools such as jq.

Search rotated and compressed logs

Logs are rotated into app.log.1, app.log.2.gz and so on. Search them all: grep ERROR app.log* for plain files, and zgrep ERROR app.log.*.gz for compressed ones.

Pitfalls

• Searching the wrong time zone and missing the event.
• Over-narrow searches that hide related lines. Start broad and tighten.
• Case and spelling. Timeout, timeout and TimedOut differ.
• Multi-line entries. A stack trace spans lines, and only the first carries the timestamp and level, so use context options to see the rest.
• Regular expression characters. ., *, [ and ( have special meaning in patterns; use grep -F for a literal string.

Before you share a log

Logs often contain tokens, addresses and personal data. Search for and remove sensitive values before sending a log to anyone. For basics see what is a log file, and for big files see how to open large log files.

Takeaway

Decide what you know, search by the most distinctive term, add context, then narrow by time, level and ID. Use Find for small logs and grep for big ones, and read the lines before the first error.