Configure Logwatch Email Reports on Debian VPS

Why Logwatch Belongs on Your Debian VPS

Most VPS owners check their server only when something breaks. Logwatch changes that habit by sending you a daily digest of what actually happened — failed logins, disk activity, service restarts, SSH access, and more — without requiring you to dig through /var/log yourself.

On a Debian VPS, the setup is straightforward. But there are a few configuration choices that determine whether those reports are genuinely useful or just noise in your inbox. This tutorial walks you through the full process: installing Logwatch, pointing it at the right log sources, formatting the output for readability, and scheduling reliable daily delivery.

If you're running a Hostperl VPS or any Debian-based server handling production traffic, this is one of the lowest-effort monitoring improvements you can make.

What You'll Need Before Starting

This guide assumes Debian 11 (Bullseye) or Debian 12 (Bookworm) and a working mail transport agent. Postfix is the most common choice. If you haven't configured outbound mail yet, install and test it first — Logwatch sends reports via the local MTA, not through an API.

You'll also need:

• Root or sudo access to the server
• A destination email address for reports (external Gmail, Outlook, or your own domain mail)
• Basic familiarity with editing files via nano or vi

Confirm your MTA is working before proceeding. A quick test:

echo "Test" | mail -s "MTA check" you@yourdomain.com

If that message arrives, you're ready.

Step 1 — Install Logwatch on Debian

Logwatch is in the standard Debian repositories. Install it with:

sudo apt update
sudo apt install logwatch

The installer pulls in Perl dependencies and places the main binary at /usr/sbin/logwatch. Default configuration lives at /usr/share/logwatch/default.conf/logwatch.conf, but you should not edit that file directly. Debian's package manager will overwrite it during upgrades.

Instead, copy it to the local override location:

sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/logwatch.conf

This is the file you'll edit throughout the rest of this tutorial.

Step 2 — Configure Your Report Destination and Format

Open the local config file:

sudo nano /etc/logwatch/conf/logwatch.conf

The key settings to review and change are:

MailTo — Set this to the address where reports should land:

MailTo = you@yourdomain.com

MailFrom — The sender address shown in reports. Using a real hostname keeps them from landing in spam:

MailFrom = logwatch@yourhostname.com

Detail — Controls report verbosity. Low gives a clean summary. Med adds moderate context. High produces verbose output that's useful for debugging but overwhelming for daily reads. Start with Med:

Detail = Med

Output — For emailed reports, keep this as mail. If you want to test output in your terminal first, set it to stdout:

Output = mail

Format — Use text for plain-text emails, which is the safest option across mail clients:

Format = text

Range — Defines which time window the report covers. yesterday is standard for daily digests:

Range = yesterday

Save the file when you're done.

Step 3 — Verify Log Source Paths

By default, Logwatch reads from /var/log. On a standard Debian install this is correct, but it's worth confirming your active services are logging there. Check that these paths exist and are populated:

ls /var/log/auth.log
ls /var/log/syslog
ls /var/log/mail.log
ls /var/log/dpkg.log

Logwatch ships with service-specific filters for Apache, SSH, sudo, cron, and more. You can see all available filter scripts at:

ls /usr/share/logwatch/scripts/services/

If you want to limit which services are included in reports — useful on a minimal server — create a services override directory and add individual service config files. For most hosting setups, the defaults cover everything relevant.

Step 4 — Run a Manual Test Report

Before scheduling anything, generate a report manually and send it to your terminal to check the output quality:

sudo logwatch --output stdout --format text --range today --detail Med

You should see sections for services like sshd, sudo, cron, and disk space. If any sections appear empty, it usually means the relevant log files haven't accumulated enough data yet, or the service hasn't been active during that window.

To do a live email delivery test:

sudo logwatch --mailto you@yourdomain.com --output mail --format text --range today --detail Med

Check your inbox. If it arrives, your MTA and Logwatch config are working correctly together. If it doesn't arrive within a few minutes, check /var/log/mail.log for delivery errors.

For tips on keeping those logs manageable as they grow, see our guide on configuring Logrotate on a Debian VPS.

Step 5 — Schedule Daily Reports with Cron

Logwatch installs a cron script at /etc/cron.daily/00logwatch automatically on Debian. Check it's present:

cat /etc/cron.daily/00logwatch

The file should contain a call to /usr/sbin/logwatch. If it's missing, create it manually:

sudo nano /etc/cron.daily/00logwatch

Paste the following:

#!/bin/bash
/usr/sbin/logwatch --output mail --mailto you@yourdomain.com --detail Med --range yesterday

Make it executable:

sudo chmod +x /etc/cron.daily/00logwatch

Debian's cron.daily jobs run via anacron, typically between 06:00 and 07:30 local server time. The exact timing depends on how /etc/anacrontab is configured. If you need reports at a precise time — say, 07:00 every morning — add a dedicated crontab entry instead:

sudo crontab -e

Add this line:

0 7 * * * /usr/sbin/logwatch --output mail --mailto you@yourdomain.com --detail Med --range yesterday

If you go this route, remove or disable the /etc/cron.daily/00logwatch file to avoid duplicate reports.

Step 6 — Tune the Report to Reduce Noise

Default Logwatch reports on a busy server can run long. A few adjustments keep them actionable.

Suppress chatty services. If your server runs a lot of cron jobs, the cron section can dominate the report. To lower its verbosity, create a service-level override:

sudo mkdir -p /etc/logwatch/conf/services/
sudo nano /etc/logwatch/conf/services/cron.conf

Add:

Detail = Low

This suppresses routine cron entries while keeping SSH and auth sections at your global Med level.

Focus on SSH failed logins. The sshd section is usually the most valuable section on a public-facing VPS. If you're running Fail2Ban alongside Logwatch (which you should be), the fail2ban log service filter shows you which IPs were banned. To enable it:

sudo nano /etc/logwatch/conf/services/fail2ban.conf

Add:

Detail = Med

For more on locking down SSH access alongside these monitoring tools, our Fail2Ban custom jails guide covers that setup in detail — the same patterns apply on Debian.

Step 7 — Keep the Config Working After Upgrades

One thing that breaks Logwatch silently on Debian is a package upgrade that resets /usr/share/logwatch/default.conf/logwatch.conf while your /etc/logwatch/conf/logwatch.conf falls out of sync with new options. Debian preserves your local config, but newly added directives won't be present unless you diff the files occasionally.

After a system upgrade, compare your local config against the updated default:

diff /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/logwatch.conf

Any lines prefixed with < are in the default but missing from yours. Review them and add what's relevant.

Also check that your cron job still runs after upgrades — a Logwatch reinstall can restore /etc/cron.daily/00logwatch with default settings, overwriting your custom mailto address.

Interpreting Your Daily Reports

Once reports are flowing, a quick daily scan takes less than two minutes. Focus on these sections first:

• sshd — Look for failed login attempts from unfamiliar IPs. A handful is normal. Hundreds from the same IP means your Fail2Ban rules need tightening.
• sudo — Lists every command run with elevated privileges. Unexpected entries here are worth investigating.
• disk space — Logwatch reports filesystem usage. A drive creeping toward 80% needs attention before it causes problems.
• postfix/sendmail — If your server sends email, this section shows delivery volumes and bounce rates. Spikes often indicate a compromised script or form.

For a broader view of what to track on a production VPS beyond log digests, the VPS monitoring guide for hosting customers in 2026 covers metrics, alerting, and tooling worth pairing with Logwatch.

Disk space alerts are also worth automating separately — our disk usage monitoring guide shows how to set threshold-based alerts so you're not relying solely on the Logwatch report cycle.

Frequently Asked Questions

Logwatch ran but I received no email — what's wrong?

Almost always an MTA issue. Run sudo logwatch --output stdout to confirm Logwatch itself works, then check /var/log/mail.log for delivery errors. Common problems include Postfix not configured for external relay, or your MailFrom address being rejected by the receiving server as unauthenticated.

Can I get reports more than once per day?

Yes. Add multiple crontab entries with different --range values. Logwatch supports today, yesterday, and date ranges like "between -1 days and today". For hourly summaries, most teams switch to a purpose-built alerting tool rather than Logwatch, which is optimised for daily digests.

How do I add custom log files to Logwatch reports?

Create a custom service filter under /etc/logwatch/scripts/services/ and a matching config file under /etc/logwatch/conf/services/. The filter is a Perl script that parses log lines and formats output. Logwatch's bundled service filters in /usr/share/logwatch/scripts/services/ are good starting templates.

Does Logwatch work with systemd journal logs?

Logwatch reads flat log files, not the binary journal directly. On Debian 12, most services still write to /var/log via rsyslog, which forwards journal entries. Confirm rsyslog is installed and running if you notice missing service sections in your reports.

Is Logwatch a replacement for a proper monitoring stack?

No — it's a reactive summary tool. It tells you what happened, not what's happening right now. For uptime alerting, response-time tracking, and real-time anomaly detection, you'll need additional tooling. Logwatch is best treated as a low-overhead daily sanity check that runs alongside, not instead of, proactive monitoring.