I like getting a daily digest of what’s happening on my servers without having to manually dig through log files every morning. Logwatch has been my go-to tool for this for years — it scans your system logs, including Apache’s, and emails you a clean, human-readable summary. Here’s exactly how I configure it.
What Is Logwatch?
Logwatch is a customizable log analysis and reporting tool. It parses log files for various services (Apache, SSH, cron, mail, and more), extracts the meaningful bits, and generates a daily (or on-demand) summary report — usually delivered via email.
Why I Use Logwatch for Apache
- Daily summaries without manual digging — instead of tailing raw logs, I get a condensed report every morning.
- Highlights anomalies — spikes in 404s, unusual user agents, or repeated errors stand out immediately in the summary.
- Low overhead — it’s a lightweight tool that runs on a schedule and doesn’t add ongoing load like continuous monitoring agents.
- Good complement to real-time tools — I pair it with server-status and Nagios for a fuller picture: real-time alerts plus a daily narrative summary.
Prerequisites
- A Linux server running Apache
- Root or sudo access
- A working mail transfer agent (postfix, sendmail, or similar) if you want email reports
Step 1: Install Logwatch
On Debian/Ubuntu:
sudo apt update
sudo apt install logwatch -y
On CentOS/RHEL:
sudo yum install logwatch -y
Step 2: Understand the Default Configuration
Logwatch’s main config file lives at:
/usr/share/logwatch/default.conf/logwatch.conf
I never edit this directly — instead, I override settings in:
/etc/logwatch/conf/logwatch.conf
Create it if it doesn’t exist:
sudo mkdir -p /etc/logwatch/conf
sudo nano /etc/logwatch/conf/logwatch.conf
Step 3: Configure Core Settings
Here’s a config I typically use:
LogDir = /var/log
TmpDir = /var/cache/logwatch
Output = mail
Format = html
Encode = none
MailTo = admin@mydomain.com
MailFrom = logwatch@mydomain.com
Range = yesterday
Detail = Med
Service = All
Let me explain the key options:
Output = mail— sends the report via email (alternatives:stdout,file).Format = html— makes the email report much easier to read than plain text.Range = yesterday— analyzes the previous full day’s logs (good for a daily cron job).Detail = Med— controls verbosity (Low,Med,High).Service = All— analyzes all supported services, not just Apache.
Step 4: Focus Specifically on Apache
If you only want Apache-related output, I limit the service list:
Service = http
Note: Logwatch’s internal service name for Apache logs is http. You can list available services with:
ls /usr/share/logwatch/scripts/services/
Step 5: Point Logwatch to the Correct Apache Log Path
Logwatch auto-detects standard paths, but if your Apache logs live somewhere non-standard, you can specify it in the service-specific config at /etc/logwatch/conf/services/http.conf:
LogFile = apache2/access.log
Or for RHEL-based systems:
LogFile = httpd/access_log
Step 6: Run Logwatch Manually to Test
Before relying on the scheduled job, I always test manually first:
sudo logwatch --detail High --service http --range today --output stdout
This prints the Apache-focused report directly to the terminal so I can review it without waiting for an email.
Step 7: Sample Output
A typical Apache section in a Logwatch report looks something like this:
--------------------- httpd Begin ------------------------
Requests with error response codes
404 Not Found
/favicon.ico: 42 Time(s)
/old-page.html: 15 Time(s)
500 Internal Server Error
/checkout.php: 3 Time(s)
Top 10 requested pages, sorted by hits:
/index.html: 3,204 Time(s)
/products.html: 1,876 Time(s)
/about.html: 654 Time(s)
Top hosts by bandwidth used:
192.168.1.20: 512 MB
203.0.113.10: 210 MB
---------------------- httpd End -------------------------
This kind of summary is exactly why I like Logwatch — the 500 errors on /checkout.php would immediately catch my attention as something to investigate further.
Step 8: Schedule Logwatch to Run Daily
Most distributions already schedule Logwatch via a daily cron job at /etc/cron.daily/00logwatch or similar. Confirm it exists:
cat /etc/cron.daily/00logwatch
If it doesn’t exist, I create one manually:
sudo nano /etc/cron.daily/logwatch-apache
#!/bin/bash
/usr/sbin/logwatch --output mail --mailto admin@mydomain.com --detail High --service http --range yesterday
Make it executable:
sudo chmod +x /etc/cron.daily/logwatch-apache
Customizing Which Details Get Excluded
Sometimes the default Apache report includes noise I don’t care about — like requests for /favicon.ico or health-check pings from a load balancer cluttering the “404” section. Logwatch lets you filter these out with an exclusion file at /etc/logwatch/conf/services/http.conf:
*OnlyService = http
*RemoveHeaders
# Ignore noisy health check requests
*Filter = /health-check
*Filter = /favicon.ico
This keeps the daily report focused on genuinely actionable information rather than routine noise from monitoring systems hitting the server every few seconds.
Generating an On-Demand Report for a Custom Date Range
While the daily cron job covers “yesterday,” I sometimes need to investigate a specific incident from a few days back. Logwatch supports custom ranges:
sudo logwatch --service http --range 'between -3 days and -1 days' --output stdout --detail High
This pulls a report covering the three days prior, which is handy when troubleshooting something a client reported a few days after it happened, and I need the historical context rather than just the most recent day.
Combining Logwatch with a Centralized Log Server
If you manage several Apache servers, running Logwatch independently on each one means checking multiple inboxes. Instead, I often forward logs to a central syslog server (using rsyslog or syslog-ng) and run Logwatch there against the aggregated logs, giving me one consolidated daily report covering the entire fleet instead of nine separate emails to sort through every morning.
Real-World Use Case
I once caught a slow-building bot attack purely from a Logwatch morning report — the “Top requested pages” section showed thousands of hits to /wp-login.php on a site that wasn’t even running WordPress. That daily summary flagged the anomaly long before it became a real problem, giving me time to add a firewall rule blocking the offending IP range.
Common Mistakes I’ve Made
- Setting
Detail = Highfor every service, which produces overwhelming, hard-to-read daily emails. I usually reserveHighdetail specifically for thehttpservice and keep others atMedorLow. - Forgetting to configure a working MTA, so reports silently fail to send. Always test with a basic mail command first.
- Not customizing
Range, leading to reports that only cover partial days depending on when the cron job runs. - Ignoring the report entirely after setup — the value only comes from actually reading it regularly.
Security Best Practices
- Send reports to an internal or restricted mailing list, not a public-facing address, since they reveal internal server details.
- Review the “top hosts by bandwidth” and “error response codes” sections regularly for signs of scanning, scraping, or brute-force attempts.
- Keep Logwatch itself updated, since it parses potentially untrusted log content.
Performance Optimization Tips
- Schedule Logwatch to run during low-traffic hours (commonly it’s already scheduled overnight by default cron jobs) to minimize any I/O contention.
- Use
Range = yesterdayrather than reprocessing the same day multiple times, which wastes CPU cycles. - If your logs are extremely large, consider rotating them daily (see my logrotate guide) so Logwatch processes smaller files each run.
Troubleshooting Common Issues
No email received — test your mail system directly: echo "test" | mail -s "Test" admin@mydomain.com. If that fails, the issue is with your MTA, not Logwatch.
Report shows no Apache data — verify the log path in /etc/logwatch/conf/services/http.conf matches your actual Apache log location.
Report is too verbose or too sparse — adjust the Detail level; I find Med works well for daily use, reserving High for deep investigations.
FAQs
Does Logwatch replace real-time monitoring tools like Nagios? No — Logwatch is a periodic summary tool, not a real-time alerting system. I use both together: Nagios for immediate alerts, Logwatch for daily narrative context.
Can Logwatch analyze logs from multiple virtual hosts? Yes, as long as all the relevant log files are in the path Logwatch is configured to scan, or you configure separate service definitions per site.
How do I reduce email volume from Logwatch? Lower the Detail level, narrow the Service list to just what you need, or switch to Output = file and review reports on your own schedule instead of via email.
Is Logwatch still actively maintained? Yes, it remains a standard package in most major Linux distributions and continues to receive updates.
Summary and Key Takeaways
Logwatch gives me an effortless daily narrative of what happened on my Apache server — top pages, error codes, bandwidth hogs, and more — delivered straight to my inbox. It’s not a replacement for real-time monitoring, but it’s an excellent complement that has caught more than one issue for me before it became a bigger problem. Setting it up takes just a few configuration tweaks and a working mail system.