How to Use tail Command in Linux: The Log Monitoring Tool Every Admin Needs

If I had to pick the Linux command I use most often during troubleshooting sessions, tail would be right up there with grep and ssh. Whether I’m watching application logs during a deployment, tracking down authentication failures, or debugging a service that won’t start, the tail command is my go-to tool for seeing what’s happening right now.

The beauty of tail isn’t just what it does – it’s how elegantly simple it is. While other log analysis tools require configuration files and learning curves, tail does one thing exceptionally well: it shows you the end of files and lets you watch them update in real-time. That simplicity is exactly why it’s been a Unix standard since the 1970s.

In this guide, I’ll walk you through everything from basic usage to advanced production techniques. By the end, you’ll understand not just how to use the tail command in Linux, but when to reach for it instead of other tools.

What is the tail Command in Linux?

The tail command displays the last portion of files. By default, it shows the last 10 lines of whatever file you point it at. It’s part of the GNU coreutils project, which means it comes pre-installed on every Linux distribution you’ll encounter.

Think of it like this: cat shows you the whole book, head shows you the opening chapter, and tail shows you the ending. For log files that keep growing, tail lets you peek at the most recent events without wading through gigabytes of historical data.

Why tail is Essential for System Administration

I learned the value of tail during my first production incident as a junior admin. A web application was throwing 500 errors, and my senior colleague typed one command: tail -f /var/log/nginx/error.log. Instantly, we watched errors stream by in real-time as users triggered them. Within 30 seconds, we identified a database connection timeout.

That’s the power of real-time log monitoring. Instead of running commands repeatedly or refreshing a file viewer, tail follows logs as they’re written. It’s like having a live feed directly into your system’s state.

For sysadmins, tail serves several critical purposes:

• Deployment monitoring: Watch application logs as code deploys to catch errors immediately
• Security auditing: Track authentication attempts and suspicious activity
• Performance debugging: Monitor slow query logs or access patterns
• Service troubleshooting: See exactly why a service failed to start

How tail Differs from Other File Viewing Tools

Linux gives you plenty of ways to view files, and knowing when to use tail versus the alternatives matters. Here’s how I think about it:

tail vs cat: Use cat when you need the entire file. Use tail when you only care about recent entries. For a 50GB log file, cat would dump everything to your terminal (don’t do this), while tail shows just the last 10 lines instantly.

tail vs less: The less command is great for interactive browsing with search and navigation. But when you want a quick glance or continuous monitoring, tail is faster. No scrolling, no interactive mode – just the data you need.

tail vs journalctl: For systemd service logs, you’ll want to how to use journalctl for systemd logs. It reads the binary journal format that systemd uses. But for plain text logs in /var/log or application-specific logs, tail is the right tool. I typically check systemd service status first, then tail the logs to see details.

Basic tail Command Syntax and Options

Let’s start with the fundamentals. The basic syntax couldn’t be simpler:

tail [options] filename

Run tail without any options, and you’ll get the default behavior – the last 10 lines:

tail /var/log/syslog

This instantly displays the 10 most recent syslog entries. No fuss, no configuration needed.

Understanding the Default Behavior

Why 10 lines? Honestly, it’s arbitrary. The original Unix developers picked 10 as a reasonable default back in the 1970s, and it stuck. For quick checks, 10 lines usually gives you enough context to see what’s happening without overwhelming your terminal.

But you’re not limited to 10. The -n option lets you specify exactly how many lines you want:

tail -n 50 /var/log/auth.log

This shows the last 50 authentication log entries – perfect for reviewing recent login attempts. You can even use the shorthand syntax without the n:

tail -50 /var/log/auth.log

Both commands do exactly the same thing. I tend to use the shorthand because it’s faster to type during late-night troubleshooting sessions.

The Most Common Options You’ll Actually Use

The official tail man page lists dozens of options, but in daily sysadmin work, you’ll use maybe five of them regularly. Here are the ones I reach for:

-n NUM (or just -NUM): Show the last NUM lines instead of 10.

tail -n 100 application.log

-f: Follow the file as it grows, displaying new lines as they’re written. This is the killer feature.

tail -f /var/log/nginx/access.log

-F: Follow with retry – handles log rotation by reopening the file if it gets renamed or deleted.

tail -F /var/log/syslog

-c NUM: Show the last NUM bytes instead of lines (rarely used, but handy for binary investigation).

tail -c 1024 large_file.bin

-s NUM: Set the sleep interval between checks to NUM seconds when following files (default is 1 second).

tail -f -s 5 low_priority.log

These options follow the POSIX specification for tail, which means they work consistently across Linux, BSD, macOS, and other Unix-like systems.

Real-Time Log Monitoring with tail -f

This is where tail transforms from a simple file viewer into an indispensable monitoring tool. The -f flag stands for “follow,” and it does exactly what you’d expect – it keeps the file open and prints new lines as they’re appended.

Following Logs as They Update

Let me show you a real scenario. You’re deploying a web application update, and you want to watch for errors as traffic hits the new code:

tail -f /var/log/myapp/error.log

Your terminal now shows the last 10 lines of the error log, then waits. As your application writes new log entries, they appear instantly in your terminal. No need to run the command again or refresh anything – it’s a live stream.

To stop following, press Ctrl+C. That’s it. The command exits, and you’re back at your prompt.

I use this constantly during deployments. I’ll SSH into a server, start tailing the application log, then trigger the deployment from another terminal. As the deployment progresses, I watch the logs stream by, ready to abort if I see errors.

When to Use -f vs -F (Capital F)

Here’s a mistake I made early in my career: I’d set up tail -f /var/log/syslog to monitor a production server, then come back hours later to find it frozen. New log entries were being written, but my tail command wasn’t showing them.

The culprit? Log rotation.

Most Linux systems use logrotate to manage log files. Every day (or when logs hit a size limit), logrotate renames syslog to syslog.1 and creates a fresh syslog file. The problem: tail -f keeps following the original file descriptor, which now points to syslog.1. It has no idea a new syslog file was created.

That’s where tail -F (capital F) saves the day. It reopens the file periodically to check if it’s been replaced. If the file gets rotated, tail -F seamlessly switches to the new file.

tail -F /var/log/syslog

For production monitoring, always use -F. It’s the difference between reliable monitoring and mysteriously frozen log tails. The logrotate documentation explains how log rotation works, but the short version is: use -F for any log that might get rotated.

Essential tail Examples for Daily Sysadmin Work

Let me share the tail commands I find myself typing most often. These aren’t theoretical examples – they’re patterns I use weekly, sometimes daily.

Viewing Specific Number of Lines

The default 10 lines often isn’t enough context. When investigating an issue, I usually want more history:

tail -n 200 /var/log/nginx/error.log

This gives me the last 200 error log entries – usually enough to spot patterns or see when an issue started. For really deep dives, I’ll go higher:

tail -n 1000 /var/log/auth.log

A thousand lines of authentication attempts can reveal brute force patterns or configuration issues that aren’t obvious from just 10 lines.

Monitoring Multiple Log Files Simultaneously

When troubleshooting complex issues, I often need to watch several logs at once. Tail handles this elegantly:

tail -f /var/log/nginx/access.log /var/log/nginx/error.log

Tail adds a header showing which file each line comes from:

==> /var/log/nginx/access.log <==
192.168.1.100 - - [03/Sep/2025:14:22:15 +0000] "GET / HTTP/1.1" 200

==> /var/log/nginx/error.log <==
2025/09/03 14:22:16 [error] 1234#0: *1 connect() failed

This is incredibly useful when debugging issues that span multiple subsystems. I can watch the web server access log and error log simultaneously, correlating requests with errors in real-time.

Combining tail with grep for Filtered Monitoring

This is where tail becomes truly powerful. Pipe its output to the grep command, and you get filtered real-time monitoring:

tail -f /var/log/auth.log | grep 'Failed password'

Now you only see failed authentication attempts as they happen. I use this constantly for security monitoring – it’s like having a specialized alert system without installing any additional software.

You can get more sophisticated with grep patterns:

tail -f /var/log/syslog | grep -E 'error|warning|critical'

This shows only log lines containing “error,” “warning,” or “critical” – perfect for catching problems across mixed log output.

Using tail with awk for Field Extraction

When you need structured data from logs, combine tail with awk for text processing. Here’s a real example I use to monitor which IP addresses are hitting a web server:

tail -f /var/log/nginx/access.log | awk '{print $1}'

This extracts just the IP address (first field) from each access log line. You see a stream of IPs in real-time:

192.168.1.100
192.168.1.101
10.0.0.5
192.168.1.100

Want to count which IPs are most active? Add sorting and counting:

tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn

This analyzes the last 5000 requests, showing IP addresses sorted by frequency. It’s quick-and-dirty traffic analysis without installing specialized tools.

Advanced tail Techniques for Production Systems

Once you’re comfortable with basic usage, these advanced techniques will make you more effective on production systems.

Handling Log Rotation with -F

I mentioned this earlier, but it’s worth emphasizing: for any production monitoring that runs for extended periods, use -F instead of -f.

tail -F /var/log/application.log

The difference is subtle but crucial. With -f, tail follows a file descriptor. With -F, tail follows a filename. When logrotate renames the file and creates a new one, -F notices and switches to the new file automatically.

You’ll see a message when this happens:

tail: '/var/log/application.log' has been replaced; following new file

This means you can set up long-running monitoring sessions without worrying about log rotation breaking them.

Monitoring Until Process Terminates

Here’s a neat trick I learned from a colleague: you can tell tail to stop following a log when a specific process ends. This is perfect for monitoring scripts or services with known PIDs.

tail -f --pid=12345 /var/log/myapp.log

Tail will follow the log file as usual, but automatically exits when process 12345 terminates. I use this when monitoring deployment scripts – the tail command automatically closes when the deployment finishes.

To find the PID you need, you might first review kill process in Linux techniques or use pgrep:

PID=$(pgrep myapp)
tail -f --pid=$PID /var/log/myapp.log

Adjusting Sleep Intervals for Performance

By default, tail -f checks for new data every second. For high-volume logs, this is perfect. But for low-activity logs or when you’re monitoring many files simultaneously, you can reduce system load by increasing the sleep interval:

tail -f -s 5 /var/log/backup.log

This checks for updates every 5 seconds instead of every second. For a backup log that only writes entries every few minutes, this reduces unnecessary file system operations.

I use longer sleep intervals when monitoring multiple low-activity logs on resource-constrained systems:

tail -f -s 10 /var/log/*.log

This monitors all log files in /var/log but only checks them every 10 seconds. Much kinder to your CPU.

Common tail Use Cases Every Admin Encounters

Let me walk through the specific scenarios where I reach for tail almost automatically.

Monitoring application deployment logs: When deploying code to production, I always have a terminal with tail -F /var/log/myapp/app.log running. The moment deployment starts, I watch for startup messages, connection confirmations, and – hopefully – no errors. If something breaks, I see it immediately rather than waiting for user reports.

Watching authentication attempts: The authentication log is goldmine for security monitoring:

tail -f /var/log/auth.log | grep 'sshd'

This shows SSH login attempts in real-time. I often run this during the first few hours after deploying a new server to make sure no unauthorized access attempts are succeeding. If you see repeated failed attempts from the same IP, you might need to adjust your firewall rules.

Following web server access and error logs: When investigating website issues, I monitor both logs simultaneously:

tail -f /var/log/nginx/access.log /var/log/nginx/error.log

This lets me correlate user requests with server errors. A user reports a 500 error? I can see their exact request in the access log and the corresponding error in the error log, usually with stack traces or database connection issues.

Debugging systemd service startup issues: When a service fails to start, the systemd journal often points to a log file for details. That’s when I tail the application’s log while attempting to start the service:

tail -f /var/log/postgresql/postgresql.log

Then in another terminal:

sudo systemctl restart postgresql

The log tail shows exactly where startup fails – missing configuration, permission errors, port conflicts, whatever. It’s faster than repeatedly checking the service status and journal.

Tracking database query logs: For performance debugging, I enable slow query logging and tail the output:

tail -f /var/log/mysql/slow-query.log

This reveals which queries are crushing performance in real-time. Combined with sed command or awk, you can extract and analyze slow queries without specialized database tools.

tail vs Other Log Viewing Tools: When to Use Which

Linux gives you a toolkit, not a single solution. Knowing when to use tail versus alternatives makes you more effective.

tail vs journalctl: Use journalctl for systemd service logs, tail for everything else. Systemd stores logs in a binary format that journalctl knows how to read. For these logs, journalctl -f -u servicename is the right choice. But for plain text logs in /var/log or application-specific logs outside systemd, tail is simpler and faster.

tail vs less: Use less when you need to browse, search, and navigate through a log file interactively. Use tail when you just want a quick peek or real-time monitoring. I open files in less when investigating historical issues, but I use tail when monitoring current activity.

tail vs cat: Never use cat for large log files. It dumps the entire file to your terminal, which can freeze your session or produce megabytes of output. Use cat for small config files, tail for logs. If you accidentally cat a huge file, press Ctrl+C quickly!

tail vs watch: The watch command for real-time monitoring is great for repeatedly running commands and seeing how their output changes. But for log files specifically, tail -f is more efficient. Watch runs commands repeatedly; tail reads files continuously.

When to combine tools: The real power comes from combining tail with grep, awk, sed, and other text processing tools. This is the Unix philosophy in action – small tools that do one thing well, combined into powerful pipelines. My most common pattern:

tail -f /var/log/syslog | grep 'keyword' | awk '{print $5}'

This follows syslog in real-time, filters for lines containing ‘keyword’, and extracts the fifth field from matching lines.

Troubleshooting Common tail Issues

Even a simple tool like tail can run into problems. Here’s how to solve the issues you’re most likely to encounter.

Permission denied errors: This is the most common issue. Many log files in /var/log are only readable by root or specific groups:

tail: cannot open '/var/log/auth.log' for reading: Permission denied

Solution: Use sudo:

sudo tail -f /var/log/auth.log

If you need to monitor logs regularly without sudo, add your user to the appropriate group (often adm or syslog):

sudo usermod -a -G adm yourusername

You’ll need to log out and back in for group changes to take effect.

File rotation causing tail -f to stop updating: I covered this earlier, but it’s worth repeating: if your tail -f command seems frozen while the log file keeps growing, you’ve hit log rotation. Kill your tail command and restart with -F instead:

tail -F /var/log/syslog

Capital F handles rotation automatically.

Performance impact of monitoring large files: If you’re tailing extremely active logs on a system under heavy load, you might notice CPU impact. Two solutions: increase the sleep interval with -s, or filter earlier in the pipeline:

tail -f -s 2 /var/log/high-volume.log | grep 'ERROR'

This checks for new data every 2 seconds instead of every second, and grep filters before displaying.

Dealing with binary files: If you try to tail a binary file, you’ll get garbage output or this message:

tail: /var/log/journal/xyz123.journal: file truncated

This happens with systemd journal files or other binary logs. Use the appropriate tool for the format – journalctl for systemd journals, specialized tools for binary database logs.

Finding log files to tail: Sometimes the challenge isn’t using tail, it’s finding the right log file. Use the find command for locating log files:

sudo find /var/log -name "*.log" -type f

This lists all log files under /var/log, helping you locate the one you need to monitor.

Final Thoughts on Mastering the tail Command

The tail command is deceptively simple. At first glance, it’s just a tool that shows the end of files. But in practice, it becomes an extension of your troubleshooting process – a way to see what’s happening on your systems right now, not five minutes ago when you last ran a command.

I’ve used tail for over a decade, and I still discover new ways to combine it with other tools. The patterns I shared here – filtering with grep, extracting fields with awk, monitoring multiple files simultaneously – these aren’t theoretical exercises. They’re techniques I used this week on real production systems.

Start with the basics: tail -f for following logs, tail -F for production monitoring that handles log rotation. Then experiment with filtering and text processing as you encounter real problems that need solving. The Unix philosophy of small, composable tools means tail plays well with everything else in your toolkit.

And remember – when a service fails at 3 AM and you need to know exactly what went wrong, tail -F will be there, quietly streaming the answers you need. That reliability is why it’s been a Unix standard for over forty years, and why it’ll remain essential for decades more.

Looking to expand your Linux command toolkit? Check out related guides on monitoring and log analysis to build a complete troubleshooting workflow.