Raw logs are useful, but they’re not something you want to read with coffee. A Logwatch setup tutorial turns the firehose into one daily email: what failed, what spiked, and what changed. If you run WordPress, mail, or a small reseller stack, that report often surfaces “quiet” issues before customers feel them.
This guide shows how to install Logwatch on Debian 12/Ubuntu 24.04+ (the same approach applies to newer 2026 point releases). You’ll tune it for web-hosting signals and deliver reports reliably. You’ll also avoid turning your VPS into an open mail relay.
What you’ll build: a daily report you can act on
By the end you’ll have:
- A daily Logwatch report emailed to you (or piped into a ticketing mailbox).
- Less noise: fewer “nothing happened” lines, more failed logins, 5xx spikes, and mail delivery warnings.
- Hosting-safe delivery: the report won’t sit in a broken local mail queue.
If you’re doing this on a new machine, start with a clean VPS. Keep networking predictable. Set correct reverse DNS.
A HostMyCode VPS gives you full root access to install Logwatch, set a proper hostname, and control outbound mail behavior.
Prerequisites (keep this tight)
- Root or sudo access
- Debian/Ubuntu with systemd
- A working MTA (Postfix recommended) or an SMTP relay account
- Access to your DNS zone if you plan to send mail off-server
If server mail identity is new territory, line up the basics early. That means hostname, rDNS, SPF, DKIM, and DMARC.
These two guides cover the practical setup work: email server hostname setup tutorial and VPS email setup tutorial.
Step 1 — Install Logwatch (Debian/Ubuntu)
Install from your distro repo. That keeps paths and service scripts aligned with your system defaults.
sudo apt update
sudo apt install -y logwatchBefore touching email delivery, confirm Logwatch produces local output:
sudo logwatch --detail high --range yesterday --service all --format textIf you get an empty report, the cause is usually one of these: journald-only logging, permissions that block reads, or services writing logs somewhere unexpected. The next steps cover common fixes.
Step 2 — Make sure Logwatch can actually read your logs
On Debian/Ubuntu, Logwatch mainly reads file logs under /var/log. If key services only log to journald, you’ll see gaps in the summary.
For hosting servers, file logs are often what you want. They’re easier to audit and retain.
Quick diagnostics
sudo ls -lah /var/log | head
sudo ls -lah /var/log/nginx 2>/dev/null || true
sudo ls -lah /var/log/apache2 2>/dev/null || true
sudo journalctl -u ssh --since yesterday --no-pager | headIf you run Nginx and don’t see access/error logs, confirm your config sets explicit log paths. This is common on minimal images.
sudo nginx -T | grep -E "access_log|error_log" | head -n 20If you also need predictable log rotation (so reports don’t grow and disk usage stays sane), pair this with our Logrotate tutorial.
Step 3 — Configure Logwatch: one place, minimal surprises
On Debian/Ubuntu, Logwatch defaults live in /usr/share/logwatch/default.conf/. Leave those alone.
Put overrides in /etc/logwatch/conf/ so package updates don’t wipe your changes.
Create the main config override:
sudo mkdir -p /etc/logwatch/conf
sudo nano /etc/logwatch/conf/logwatch.confUse a practical baseline for hosting servers:
# /etc/logwatch/conf/logwatch.conf
MailTo = ops@example.com
MailFrom = logwatch@your-hostname.example
Range = yesterday
Detail = Med
Service = All
Format = text
Output = mail
Encode = none
# Reduce duplicate chatter
Hostname = your-hostname.exampleNotes that save time:
Detail=Medis usually the sweet spot. High detail can drown the signal.MailFromshould use a domain you control. Random From addresses are easy to filter.- If you manage multiple VPS nodes, set
Hostnameso the subject line is instantly clear.
Step 4 — Tune what Logwatch reports (focus on hosting signals)
Most hosting admins watch the same categories: SSH auth failures, web server errors, mail delivery problems, and resource warnings.
The goal is simple: cut junk, and make the important sections readable.
4.1 Suppress low-value services
Create a services override file:
sudo mkdir -p /etc/logwatch/conf/services
sudo nano /etc/logwatch/conf/services/zz-hosting.confExample: skip services that often add pages of “FYI” output on small servers (adjust to your stack):
# /etc/logwatch/conf/services/zz-hosting.conf
# If you don't use these, disable them to cut noise.
#Service = "-zz-disk_space"
#Service = "-eximstats"
#Service = "-postgresql"
#Service = "-named"
# If you DO run mail and web, keep them and consider higher detail.
# (Service control is often best managed by command flags; see cron below.)Service names vary a bit by distro package and what’s installed. To see what Logwatch recognizes on your server:
sudo logwatch --service all --print --range yesterday 2>/dev/null | head -n 504.2 Increase detail for SSH and web errors
Instead of turning the entire report up to “High,” tune the command you run daily. The cleanest pattern is a dedicated cron job (next step) with an explicit service list.
Common “hosting signals” services to include:
- sshd (auth failures, invalid users)
- nginx or apache (5xx, suspicious URLs)
- postfix or exim (bounces, deferrals, queue growth)
- cron (failing jobs; WordPress scheduled tasks often surface here)
If you’re chasing unexplained 500s or sudden bot spikes, keep a “deep dive” flow handy: VPS log analysis tutorial.
Step 5 — Schedule daily emails (cron) with a predictable subject
Debian’s Logwatch package often ships with a daily cron job. It works, but it’s generic.
For hosting ops, you’ll want control over the subject line, the services included, and the verbosity.
Create your own cron file. Disable the default if needed.
5.1 Check the existing Logwatch cron
ls -lah /etc/cron.daily | grep -i logwatch || true
sudo cat /etc/cron.daily/00logwatch 2>/dev/null || trueIf it exists and you plan to replace it, rename it (safer than deleting):
sudo mv /etc/cron.daily/00logwatch /etc/cron.daily/00logwatch.disabled 2>/dev/null || true5.2 Add a custom cron entry
Create a cron job that runs at 07:15 server time:
sudo nano /etc/cron.d/logwatch-hosting# /etc/cron.d/logwatch-hosting
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
15 7 * * * root /usr/sbin/logwatch --range yesterday --detail Med --format text --output mail --mailto ops@example.com --service sshd --service nginx --service postfix --service cron --hostname $(hostname -f) --subject "[Logwatch] $(hostname -f) daily report"Adjust services to match your stack. Use apache instead of nginx, or drop postfix if you don’t run mail locally.
Step 6 — Make delivery reliable (Postfix local-only or SMTP relay)
A daily report is only useful if it arrives every day. On VPS hosting, two delivery patterns tend to work well.
Option A: Local-only Postfix (recommended for most web-only servers)
This keeps Postfix from behaving like a public mail server. Mail is generated locally, then forwarded via a relay (or you read it on the box).
The risk surface stays small.
Install Postfix in “Local only” mode:
sudo apt install -y postfix mailutilsDuring the prompt, pick Local only. Then verify:
sudo postconf -n | sed -n '1,120p'
sudo systemctl status postfix --no-pagerOption B: Configure Postfix to relay through an authenticated SMTP provider
If you want Logwatch reports delivered to external inboxes without fighting outbound reputation, relay through a provider (or your business mail host).
Provider specifics vary, but the building blocks don’t. You still need relayhost, SASL credentials, and TLS.
Example (generic) Postfix relay config:
sudo postconf -e 'relayhost = [smtp.yourprovider.com]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo nano /etc/postfix/sasl_passwd[smtp.yourprovider.com]:587 USERNAME:PASSWORDLock permissions, build the hash db, and reload:
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfixIf mail gets stuck, don’t guess. Trace it by queue ID and logs.
These two tutorials are built for that workflow: Email log troubleshooting tutorial and VPS mail queue troubleshooting tutorial.
Step 7 — Test end-to-end (don’t trust cron)
Run Logwatch manually first. Confirm you receive the message.
sudo logwatch --range yesterday --detail Med --format text --output mail --mailto ops@example.com --service sshd --service cron --hostname $(hostname -f) --subject "[Logwatch TEST] $(hostname -f)"Then confirm your MTA actually sent it:
sudo tail -n 80 /var/log/mail.log 2>/dev/null || true
sudo journalctl -u postfix --since "10 minutes ago" --no-pager 2>/dev/null || true
sudo mailq 2>/dev/null || trueIf nothing arrives, it’s usually one of these:
- Outbound SMTP blocked by policy or firewall
- Bad relay credentials or TLS failure
- From/hostname mismatch causing filtering (common on strict corporate inboxes)
- Mail goes to spam because SPF/DKIM/DMARC are missing for the From domain
Step 8 — Make the report more useful for web hosting
Logwatch tells you what happened. You still need a few simple “if you see X, do Y” rules.
That’s what turns a summary into actions.
8.1 SSH auth failures: decide whether to harden or to block
A steady stream of SSH failures is normal background noise. Watch for repeated attempts against real usernames.
Also watch for successful logins from an IP you don’t recognize.
Action checklist:
- Disable password auth and require keys
- Limit SSH to your office IPs where possible
- Add rate-limiting / banning for repeated failures
For the hands-on steps, follow SSH lockdown tutorial. It pairs well with Logwatch because your daily report becomes the “did the hardening actually reduce noise?” check.
8.2 Nginx/Apache errors: correlate with deployments and plugins
If you see 404 spikes, you’re usually looking at bots or broken internal links.
If you see 500/502/504, suspect PHP-FPM crashes, upstream timeouts, or filesystem permissions.
Two quick commands that save time:
# Top 20 URLs returning 500 from Nginx access logs (adjust path)
sudo awk '$9 ~ /^5/ {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20
# Recent PHP-FPM errors (common path on Ubuntu)
sudo tail -n 120 /var/log/php8.3-fpm.log 2>/dev/null || trueIf WordPress updates are failing and Logwatch hints at permissions or filesystem errors, fix it using WP-CLI troubleshooting instead of clicking around wp-admin and hoping it clears up.
8.3 Mail warnings: treat deliverability as part of uptime
Even if your VPS only sends a handful of messages (password resets, order emails), mail failures still read as “the site is broken” to customers.
If you host email on the VPS, don’t stop at “it sends.” Sign outbound mail with DKIM and verify alignment.
This guide walks through a stable OpenDKIM + Postfix setup: DKIM setup guide tutorial.
Step 9 — Security baseline: don’t let Logwatch report a problem you could have prevented
Logwatch helps you detect issues. It doesn’t prevent them.
A basic hardening baseline reduces the number of bad events you’ll ever need to read about.
- TLS hardening for modern ciphers and correct headers on HTTPS endpoints
- Web application firewall rules if you host WordPress on a public login/admin surface
- Patch discipline so known issues don’t linger for months
If you want a practical WAF layer for WordPress traffic, use this ModSecurity + OWASP CRS tutorial.
It complements daily summaries nicely because you’ll see attack volume and blocked patterns show up in the reporting.
Step 10 — Troubleshooting: common Logwatch gotchas on VPS hosting
“Logwatch report is empty”
- Confirm logs exist under
/var/logand contain entries for yesterday. - Run Logwatch with
--debug highto see what it’s parsing.
sudo logwatch --range yesterday --detail Med --service sshd --debug high 2>&1 | tail -n 80“Report is huge and unreadable”
- Lower global detail:
Detail=LoworMed - Limit services in your cron command
- Fix log rotation so old entries don’t get reprocessed oddly
“Emails don’t arrive / go to spam”
- Use a From domain you control and publish SPF
- Prefer SMTP relay for consistent delivery
- Ensure your server hostname and SMTP banner are sane
Operational checklist (print this)
- Install Logwatch and run it manually once
- Override config in
/etc/logwatch/conf/logwatch.conf - Create a custom cron job with explicit services
- Make mail delivery reliable (local-only or SMTP relay)
- Read the report daily for 7 days and tune noise down
- Write down the three actions you take most (block IP, fix permissions, restart PHP-FPM) and standardize them
If you want daily reporting without babysitting the server underneath it, run Logwatch on a VPS that’s designed for hands-on administration. Start on a HostMyCode VPS, or use managed VPS hosting if you’d rather hand off OS updates, mail plumbing, and routine maintenance.
FAQ
Does Logwatch work with journald-only logging?
Logwatch works best with file logs in /var/log. Journald is still useful for investigations. For clean daily summaries, enable file logging for Nginx/Apache, SSH, and mail.
Should I run Logwatch on shared hosting?
Most shared hosting plans don’t give you root access or full log visibility, so Logwatch isn’t a good fit. It’s meant for VPS and dedicated servers where you control log paths and mail delivery.
What’s the best frequency: hourly or daily?
Daily is a solid baseline for small and mid-sized hosting servers. If you need faster reaction time, add separate real-time alerts for specific events (disk full, load spikes) and keep Logwatch as the daily digest.
Which services should I include for a WordPress VPS?
Start with sshd, nginx or apache, php-fpm (if supported by your Logwatch scripts), cron, and your MTA if you send mail locally.
Summary: treat the daily email as part of server hygiene
A Logwatch report won’t replace real monitoring. It’s a low-effort habit that catches misconfigurations, brute-force noise that turns into real risk, and mail failures that break user workflows.
Once services and delivery are tuned, the daily read takes a minute. It can save hours of reactive debugging.
If you’re rolling this out across multiple client servers, standardize your baseline on HostMyCode VPS plans (or managed VPS hosting if you want help with upkeep). Consistency is what makes daily reporting stick.