Skip to main content

--

Logwatch logging monitor

Overview​

Logwatch is a log analysis and reporting tool that summarizes system and application logs into a readable daily (or on-demand) report. It helps operators spot anomalies such as repeated authentication failures, unexpected service restarts, mail queue issues, and web server errors without manually tailing multiple log files.

History​

  • As Linux systems accumulated more services and log files, daily summary reporting emerged as a practical way to review “what changed” on a server.
  • Logwatch became widely used on traditional Linux servers because it can parse common log formats and produce concise reports with minimal configuration.

Adoption​

Logwatch is commonly used in:

  • VPS and bare-metal Linux servers using file-based logs (syslog/rsyslog, auth logs, mail logs)
  • Small fleets that want quick daily health summaries without a full SIEM
  • Security hygiene workflows that review authentication events and unusual activity
  • Environments running classic web/mail stacks (Apache/NGINX, Postfix, Dovecot)

Maintainer​

Maintained by the Logwatch project/community and packaged by Linux distributions.

Best when to use​

  • You want daily summaries of important log events without building a full monitoring stack
  • You need a lightweight tool that runs locally and can email reports
  • You are troubleshooting recurring issues and want consistent periodic snapshots

Not suitable when​

  • You need real-time alerting and incident response automation
  • Logs are primarily in journald only and not forwarded to files (unless configured)
  • You require centralized correlation across many hosts (use a SIEM/log platform)

Compatibility notes​

  • Logwatch primarily reads file-based logs under /var/log. If your system relies heavily on systemd-journald, ensure logs are forwarded to files or use journald-specific tooling.
  • Log file locations vary by distro (/var/log/auth.log vs /var/log/secure, etc.).
  • Emailing reports requires a working local MTA or relay configuration.
Scope

This page covers safe installation, local report generation, common configuration patterns, and operational troubleshooting for VPS environments.

How it works​

Logwatch runs scripts that:

  1. Collect relevant log entries for a time range
  2. Group and summarize them by service (SSH, sudo, cron, web server, mail)
  3. Output a report to stdout or send it by email

Key operational points:

  • Logwatch is a summarizer; it does not change log retention or rotation.
  • Output depends on enabled services and which log files exist on your system.
  • The “detail level” controls how much raw log context is included.

Installation​

sudo apt update
sudo apt install logwatch

Verify installation (read-only)​

logwatch --version 2>/dev/null || true
logwatch --help | head -n 30

Configuration locations​

PathPurpose
---
/usr/share/logwatch/Default scripts and service definitions
/etc/logwatch/System-wide configuration overrides
/etc/logwatch/conf/logwatch.confMain configuration file (varies by distro)
/etc/cron.daily/Common place where scheduled runs are triggered

List current config files (read-only):

sudo find /etc/logwatch -maxdepth 3 -type f 2>/dev/null | sort

Generating reports (safe, on-demand)​

Run a report for today​

sudo logwatch

Run a report for yesterday​

sudo logwatch --range yesterday

Run a report for the last 7 days​

sudo logwatch --range "between -7 days and today"

Increase or decrease detail​

sudo logwatch --detail low
sudo logwatch --detail med
sudo logwatch --detail high
Sensitive log content

Higher detail levels can include usernames, IP addresses, and request paths. Treat reports as sensitive data.

Limit to specific services​

Common service names include sshd, sudo, cron, apache, nginx. List available services by inspecting /usr/share/logwatch/scripts/services/.

Example:

sudo logwatch --service sshd --range yesterday --detail med

Write output to a file​

sudo logwatch --range yesterday --detail med > /var/tmp/logwatch-yesterday.txt

Scheduling (daily summaries)​

Many distributions install Logwatch with a daily cron job. Confirm with:

ls -la /etc/cron.daily/ | grep -i logwatch || true

If your distro uses systemd timers for scheduled jobs, confirm timers:

systemctl list-timers | grep -i logwatch || true

Emailing reports​

Logwatch can send output via email if a mail transfer agent (MTA) is configured on the host (local Postfix, ssmtp, or a relay).

Common configuration fields include:

  • MailTo
  • MailFrom
  • Output = mail

Example override file pattern (do not edit vendor defaults directly):

  • /etc/logwatch/conf/logwatch.conf or /etc/logwatch/conf/logwatch.conf.d/local.conf (varies)

Example config snippet:

MailTo = ops@example.com
MailFrom = logwatch@example.com
Output = mail
Detail = Med
Range = yesterday
Email delivery

If the server cannot send mail, reports will not arrive. Validate mail delivery separately using your MTA’s logs and a known test message.

Practical use cases​

VPS security hygiene (SSH and sudo)​

Run a daily report focusing on auth-related services:

sudo logwatch --service sshd --service sudo --range yesterday --detail med

Look for:

  • Repeated failed logins from the same IP
  • Successful logins from unusual IP ranges
  • New sudo usage or unfamiliar command patterns

Web server error review​

For Apache or NGINX (depending on your stack):

sudo logwatch --service apache --range yesterday --detail med
# or
sudo logwatch --service nginx --range yesterday --detail med

Look for:

  • Spikes in 404/500 responses
  • Unusual user agents
  • Repeated requests to sensitive paths (for example, .env, wp-config.php)

Track cron activity​

sudo logwatch --service cron --range yesterday --detail low

Troubleshooting​

Report is empty or missing expected sections​

Common causes:

  • Logs are in journald only and not written to /var/log
  • The service log file path differs on your distro
  • Permissions prevent logwatch from reading logs (run with sudo)

Checks (read-only):

ls -la /var/log | head
sudo journalctl -n 50 --no-pager 2>/dev/null | head -n 20 || true

If your system uses journald, consider enabling persistent journal storage and/or forwarding to syslog/files (via rsyslog or journald settings).

“Unknown Service” errors​

Cause: service name not recognized by installed logwatch scripts.

Fix:

  • List available service scripts:
ls -1 /usr/share/logwatch/scripts/services/ 2>/dev/null | head

Use the script name without file extension.

Email reports not delivered​

Causes:

  • No MTA installed or configured
  • Firewall blocks outbound SMTP
  • Mail relay rejected the message

Checks:

command -v sendmail 2>/dev/null || true
sudo tail -n 100 /var/log/mail.log 2>/dev/null || true
sudo tail -n 100 /var/log/maillog 2>/dev/null || true

Security notes​

  • Reports may contain usernames, IP addresses, request paths, and error traces.
  • Restrict access to /var/tmp reports and email recipients.
  • Use least privilege: only administrators should run high-detail reports.
Data handling

Do not forward full high-detail reports into untrusted channels. Summaries can reveal internal hostnames, admin accounts, and traffic patterns.

Quick reference​

TaskCommand
---
Run today’s reportsudo logwatch
Run yesterdaysudo logwatch --range yesterday
Last 7 dayssudo logwatch --range "between -7 days and today"
Medium detailsudo logwatch --detail med
SSH-only reportsudo logwatch --service sshd --range yesterday --detail med
Write to filesudo logwatch --range yesterday --detail med > /var/tmp/logwatch.txt
Check cron jobls -la /etc/cron.daily/ | grep -i logwatch
List service scriptsls -1 /usr/share/logwatch/scripts/services/