Why this exists: a log file printed once shows you the past — but incidents, deploys and bug hunts happen now. The fix was a flag that keeps the file open and streams every new line the moment it lands. It stuck, one big reason being that the habit transfers everywhere: containers, clusters and system services all grew a follow mode that works the same way.

The command and its shape

Logs are where services narrate their lives, and the end of the log is "now". tail shows a file's end; the -f flag (follow) keeps it attached and streams each new line as it is written:

tail -f /var/log/api.log          # follow new lines live
tail -n 100 -f /var/log/api.log   # last 100 first, then follow
tail -f api.log | grep -i error   # follow, errors only

Ctrl+C detaches when you are done — the service is unaffected; you were only reading. Two details worth knowing: tail -f follows the file it opened, so if the log is rotated (renamed and replaced by a fresh file) the stream goes quiet. tail -F follows the name and re-opens the new file. And tail -f shows lines the moment they are written; if a program buffers its own output before writing, that delay is the program's, not tail's.

Terminal A · the cause

$ systemctl restart api
$ curl -i localhost:8080/orders
HTTP/1.1 200 OK

Terminal B · the effect, as it lands

12:52:01 INFO  api stopping (SIGTERM)
12:52:01 INFO  closed 3 db connections
12:52:02 INFO  api starting v2.4.1
12:52:02 INFO  listening on :8080
12:52:03 INFO  request GET /orders 200 38ms
▮
All six lines are shown. Press Play to see them arrive one at a time, as tail -f would show them.
Cause on the left, effect on the right. You restart the service in one terminal; tail -f /var/log/api.log in the other shows the shutdown, the start-up and the first successful request the moment each is written.

The wrong tools people reach for first

cat dumps the whole file once and exits — you would miss everything that happens next. Plain tail without the flag shows the last ten lines and exits, a snapshot when you wanted a stream. head shows the beginning of the file — the oldest lines, exactly the wrong end for live debugging. The tell in all three: they exit. Live watching needs the one that stays.

The same idea, everywhere you'll work

The follow habit transfers wholesale. less +F file follows inside a pager, so you can pause and scroll back. journalctl -u api -f is the identical idea for system services on modern Linux. docker logs -f name and kubectl logs -f pod are the same concept for containers and clusters. Learn the flag once here, and you already know how to watch anything.

The pro habit

During any change, engineers run two terminals: one making the change, one running tail -f on the relevant log. Cause on the left, effect on the right — you watch your deploy land, your error reproduce, your fix take effect, live. And when the log is noisy, the pipeline you already know cuts it down: tail -f api.log | grep -i error — follow the file, keep only the bad news.

After this, you can: watch any log as it is written, start the view with recent history, filter the stream to what matters, and carry the same follow habit to services, containers and clusters.