How to find errors in a log file on Mac

You have a log open. Somewhere in it a request failed, a service refused to start, or a job died at 03:14. Scrolling is not a search strategy. What you want is to press a key, land on the next failure, and keep pressing.

This guide covers the error-jump keys in Note My, the exact words they recognise, what to do when your failures are spelled differently, and how to count what you found.

Reach the failures

1. Open the log

   Press ⌘O and choose the file, or drag it onto the tab bar. For a rotated log with a number on the end — access.log.1, server.out.3 — reach for ⇧⌘O instead: File ▸ Open Anything as Text… opens a file as text whatever its extension says. It is the quickest way into a whole rotation, and it saves renaming a file you would rather leave exactly as your service wrote it. Each log arrives in a tab of its own, so yesterday's file and this morning's can stay open together while you work through both.

2. Turn the colour on

   Choose View ▸ Enable Log Highlighting, or click the Log pill in the status bar. Our syntax engine picks out severity keywords, ISO-8601 timestamps, HTTP status codes, IPv4 addresses, UUIDs and URLs, so a bad request stands out at a glance. None of it changes the file: the colour is on screen only, and what is on disk stays as it was.

3. Jump to the next failure

   Press ⌥⌘E for Jump to Next Error in the Search menu. The caret moves to the next matching line and a brief message reads "Jumped to line N."

4. Step back through them

   ⌥⇧⌘E is Jump to Previous Error. Both directions wrap: from the last error, forward takes you to the first. Both keys work the moment a log is open, with or without log highlighting on, so you can start walking a file the second it lands on screen.

Exactly which words count as an error

The jump keys recognise the six severity words that most logs already write. Case does not matter, and the word has to stand on its own rather than sit inside a longer one, so a field named error_rate never interrupts a walk through real failures:

Two things follow from that. Warnings count as failures for navigation, which is usually what you want at three in the morning: the WARN lines running up to a crash are the first half of the story, and the keys walk you through them in order rather than dropping you at the end. And case is ignored while whole words are what count, so error, Error and ERROR all stop the caret while a metric name that merely contains those letters lets you pass.

Colour is broader than jumping. Log highlighting marks the quieter levels too, so the INFO line that gives a failure its context stays in plain view while you walk the failures themselves. Levels that mean the same thing share a colour, which is what makes the pattern readable at a glance — FATAL, CRITICAL and SEVERE read as one band, as do WARN and WARNING, and DEBUG, TRACE and VERBOSE, while ERROR, NOTICE and INFO each stand apart. Scroll quickly and the colour alone tells you a page's severity mix before you have read a word of it, which is often enough to tell a noisy stretch from the minute the incident began.

Walking the whole log without losing your place

Each press takes you to the nearest failure on the side you asked for. Error jumping reaches the whole file: a failure near the end of an overnight log is as reachable as one on the first screen. Past the last match, the next press returns to the first, so the keys never dead-end.

Use that wrap deliberately. Start at the top, press forward until the line numbers stop rising, and you have seen every failure once. Then step backwards from the earliest one that looks like the start of the incident. Our large-file engine keeps that loop quick on logs far too big to scroll by hand.

Opening Find and Replace

Click the magnifying-glass button in the toolbar. The popover has a find field, a replace field, a scope control reading This File / All Tabs, and three checkboxes: Case Sensitive, Whole Word and Regular Expression. Typing highlights every match live and shows a running count. ↩ steps forward, ⇧↩ back, ⎋ closes it and clears the highlights. The field remembers your recent searches.

Catch failures spelled any other way

Plenty of software never writes the word ERROR. Some logs use FAIL, some a single-letter level, some only an HTTP status code. For those, tick Regular Expression in the popover above; the find field then takes a standard regular expression, which our find and replace steps through as it does plain text.

(?i)\b(fail|failed|failure|panic|abort)\b
\b5\d{2}\b
^\S+ \S+ \[(?:E|F)\]
\b(?:\d{1,3}\.){3}\d{1,3}\b .* 4\d{2}
^\s+at [\w.$]+\(

The first catches a log that says fail, panic or abort in any casing. The second finds 5xx responses. The third anchors to a line's own level marker rather than the message text; the fourth pairs an IPv4 address with a 4xx status on one line. The fifth picks up the indented frames of a stack trace, so ↩ walks you down the trace one frame at a time.

Leave that box unticked and what you type is matched literally, brackets, dots and all — the same field serves both ways of searching, so you can switch between them mid-incident. While the box is ticked, an expression that is still half-written names its own problem: the status label reads "Invalid pattern:" followed by the reason, so a stray bracket tells you it is the stray bracket and you can correct it in place with the rest of the query still in the field.

Counting what you found

Once a search is running, choose Count Matches from the Search menu. A brief message reports "N matches on M lines." — two numbers rather than one, because forty errors on three lines is a very different incident from forty on forty lines.

The answer comes back straight away, even on a very large log. It counts whatever search is live in the popover, so you can sharpen the query and count again, watching the number fall until it describes the incident rather than the log.

An enormous number is itself a finding, and the status label tells you when you are in that territory. Read it as the cue to sharpen: a query matching that heavily is describing the whole log rather than your incident. Add a word, anchor the pattern with ^ so it matches only at the start of a line, or pair a severity with the component name that owns the failure. Two or three passes like that usually take a whole night of logging down to the dozen lines that describe what went wrong, and stepping through the matches with ↩ works the same at every stage.

Marking every error so you can walk the list

A jump key reads forward; bookmarks give you the whole set at once. With a search active, press Bookmark All in the find popover — or ⌥⌘B for Bookmark All Search Matches — and every matching line gets a dot in the gutter. F2 and ⇧F2 then step to the next and previous bookmark, and ⌘F2 toggles one by hand. Right-clicking the gutter offers a single item that flips between "Add Bookmark to Line N" and "Remove Bookmark from Line N".

The Search menu then offers Copy Bookmarked Lines, which lifts just those lines to the clipboard — a fast way to hand a colleague the twelve lines that matter. The same block carries Invert Bookmarks With Matches, a Clear command, and Delete Bookmarked Lines, which removes those lines from the document and asks first by default.

Errors spread across a folder of logs

When the incident spans a directory of rotated files, use Search ▸ Find in Folder… (⇧⌘F). It stays open while you work. Results arrive grouped by file with line numbers and a short preview of each line; double-click a row to open that file at that line. Noise directories such as .git, node_modules, build, .build and DerivedData stay out of the results, and the same case, whole-word and regular-expression options are there.

Search for a request ID rather than a severity when you have one: it appears in every service that handled the request.

Find in Folder only ever reads: it never writes to a file it searches, by design. The search runs on your Mac, so a directory of production logs stays exactly where it is and nothing about it leaves the machine.

Troubleshooting

My log spells its failures differently

This log spells its failures its own way — FAILED, or a single-letter level such as E/AppName. Open the find popover, tick Regular Expression and search for the form your log actually writes. ↩ then steps through the matches exactly as the jump keys do, and Bookmark All marks the whole set in the gutter in one press.

I want stops only on real severity lines

Anchor the search to the line's own level field rather than to its message text, and the caret stops only where the log itself declares a severity — ^\S+ \S+ \[(?:E|F)\] is the shape, adjusted to the format in front of you. It is also how you set the WARN lines aside on a chatty service and walk the failures alone. Type the expression once and leave it in the find field; it stays in your recent searches for the next log you open.

Count Matches works from a live search

Type your query in the find popover and leave the popover open, then choose Count Matches while the highlights are still on screen. Keeping it open also lets you adjust the query and count again in the same breath.

I need every occurrence of one identifier in a huge log

Search for it in the find popover. Every occurrence is marked at once and the running count tells you how many there are, which is more than a highlight would have told you. Our large-file engine keeps that quick whatever the log weighs, so a request ID in an overnight file comes back without a wait, and Bookmark All turns the result into a list you can step through with F2.

The log is unreadable — wrong characters everywhere

The file was opened with the wrong encoding. Use File ▸ Encoding ▸ Reload with Encoding… and pick the encoding the file was written in; our encoding handling shows the same file read the way you chose, and changes nothing on disk. Convert to Encoding… is the opposite operation and does change what gets written, so do not reach for it here.

The file keeps changing under me

An active log will. You are told, and offered Reload or Keep My Version. For new lines continuously rather than a prompt each time, turn on View ▸ Follow Tail.

Carry the incident to a conclusion

Landing on the failing line is the start of the job rather than the end of it. These are the moves that take you from the first stop to something you can hand over, and they use the same search you have already typed.

• Put a good run beside the bad one. When one deployment logs cleanly and the next does not, open both files and use the Compare menu in the toolbar — Quick Compare pairs them without any picking. Our comparison view marks the differing lines in the text itself, in both panes at once, so the moment the two runs part company is the first thing you read.
• Lift the failures out of the noise. Search, press Bookmark All, then choose Copy Bookmarked Lines. The clipboard holds those lines and nothing else, in file order, ready to paste into a ticket or a message to whoever owns the service.
• Cut a working copy down to the incident. Mark the lines you do not need and Delete Bookmarked Lines clears them in one go, with Invert Bookmarks With Matches to flip the set when marking the keepers is the quicker way round. Nothing on disk changes until you save, so you can carve the copy about freely.
• Keep the query for next time. The find field remembers your recent searches, so the regular expression you worked out at three in the morning is a keystroke away the next time the same service misbehaves — and the same expression works in Find in Folder when the next incident spans the whole rotation.
• Correct the same line everywhere at once. Replace in All Files in the find popover reaches every tab you have open, so a fix you type once lands in each of the logs you are working through.
• Watch the next failure arrive. View ▸ Follow Tail keeps the newest lines in view as the service writes them, so a log you already have open stays current while you read it.