`tail -f` Is Still the Log Command You Should Reach For When You Need Live Proof, Not a Postmortem Written After the Fact

Why this command matters: a surprising amount of debugging improves the moment you stop reading stale logs and start watching the system react in real time.

When an endpoint fails, a cron job mysteriously does nothing, or a worker seems stuck, historical logs help. But live observation is often better. That is exactly what tail -f is for.

The basic command

tail -f /var/log/my-app.log

The -f means follow. As new lines are appended to the file, they stream into your terminal.

That sounds basic because it is basic. It is also incredibly useful when you need to correlate an action with the exact log lines it triggers.

Why live following beats static reading

Suppose you are testing a webhook. If you only inspect the file afterward, you may miss timing, retries, duplicate events, or the order in which related services reacted.

With tail -f, you can:

1. trigger the request
2. watch the app receive it
3. see downstream errors immediately
4. confirm whether a retry or background job followed

That turns “I think it processed something” into “I watched the system do exactly this.”

Practical variations

Show the last 100 lines and keep following:

tail -n 100 -f /var/log/my-app.log

Follow multiple files:

tail -f /var/log/nginx/error.log /var/log/my-app.log

Pipe it into grep for a narrower signal:

tail -f /var/log/my-app.log | grep ERROR

These patterns make tail -f more than a passive scrolling wall.

Common scenarios where it helps

It is especially useful for:

1. reproducing API failures
2. checking whether a worker picked up a job
3. watching a deploy hit startup logs
4. verifying that a background script is writing anything at all
5. confirming a reverse proxy is reaching the app

If the system is supposed to react to something right now, a live log view is usually more informative than a retrospective guess.

Common mistake

The common mistake is tailing the wrong file or only the application file when the real failure lives in another layer. For example, an nginx access log may prove the request never reached the app, while the app log sits uselessly quiet.

A better pattern is to choose the file that corresponds to the boundary you are testing:

1. proxy log for incoming traffic
2. app log for routing and handler behavior
3. worker log for queue execution
4. system log for service-level failures

Final recommendation

When you need live confirmation that something is or is not happening, use tail -f instead of arguing from old log files and memory. Real-time visibility often cuts debugging time more than any clever theory does.

Sources

• GNU Coreutils tail manual