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.
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.