Logwatch Setup Tutorial (2026): Daily Security & Service Reports on an Ubuntu Hosting VPS

You can run a “healthy” VPS for weeks and still miss early warnings. Think repeated SSH auth failures, a bot hammering wp-login.php, or disk space shrinking because logs never stop growing. This logwatch setup tutorial shows you how to turn Ubuntu hosting logs into a readable daily email. You’ll spot problems while they’re still easy to fix.

The steps assume a typical hosting stack: Nginx or Apache, PHP-FPM, SSH, UFW, Fail2Ban, and sometimes Postfix. You’ll install Logwatch, limit it to the services you care about, and make sure the report reliably lands in your inbox.

What you’ll build (and why it matters on a hosting VPS)

Logwatch reads common Linux log files and produces a daily summary. On a hosting VPS, it helps you catch slow-burn issues that uptime checks miss. That includes authentication noise, periodic 500s, broken cron jobs, certificate renewal errors, and early disk pressure.

• Daily email report at a predictable time (via cron).
• Noise control so the report stays readable.
• Actionable sections for SSH, sudo, web server, firewall/UFW, Fail2Ban, and disk-usage hints.

If you run customer sites or business-critical traffic, this is a low-effort safety net. It also fits nicely into a clean new server build on a HostMyCode VPS. You get visibility without standing up a full monitoring stack on day one.

Prerequisites and assumptions

• Ubuntu Server (22.04 LTS or 24.04 LTS are common in 2026) with sudo access.
• System logs available in journald and/or files under /var/log.
• Outbound email capability (either local Postfix, or a relay provider).

If SSH isn’t hardened yet, do that first. Logwatch will show brute-force attempts, but it won’t stop them. Use this guide for hardening: SSH lockdown tutorial.

Step 1: Install Logwatch on Ubuntu

Logwatch is available in the Ubuntu APT repo. Update your package list and install:

sudo apt update
sudo apt install -y logwatch

Run it once manually to confirm it can parse logs. This sends output to your terminal:

sudo logwatch --range yesterday --detail high --service all --output stdout

If the output is massive on a busy host, that’s normal. The next steps trim it down.

Step 2: Create a safe Logwatch configuration (don’t edit the defaults)

On Ubuntu, Logwatch defaults live in /usr/share/logwatch/default.conf/. Leave those files alone. Put your overrides in /etc/logwatch/conf/ so upgrades don’t overwrite your changes.

Create the main config file:

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

Use this baseline config aimed at hosting operations:

# /etc/logwatch/conf/logwatch.conf
Output = mail
Format = text
Range = yesterday
Detail = Med
MailTo = you@example.com
MailFrom = logwatch@yourhostname
TmpDir = /var/cache/logwatch

# Start conservative; raise later.
Service = "sshd"
Service = "sudo"
Service = "cron"
Service = "ufw"
Service = "fail2ban"
Service = "nginx"
Service = "apache"

# Helpful when debugging missing sections
# LogDir = /var/log

Pick one web service: if you only run Nginx, remove the Apache line (and vice versa). Keeping both on a typical VPS adds clutter. It can also push the important sections down the page.

Step 3: Make sure email delivery works (the part most people skip)

Logwatch can generate perfect reports and still be useless if the VPS can’t deliver mail. On hosting servers, you usually end up with one of these setups:

• Local Postfix with proper DNS (best if you also host mail).
• SMTP relay (best if the VPS only sends notifications).
• Send to a local mailbox and forward (works, but adds a maintenance step).

Start with a quick send test from the server:

echo "Logwatch mail test" | mail -s "Logwatch test" you@example.com

If nothing arrives, check mail logs immediately. Common places to look:

sudo journalctl -u postfix --since "10 minutes ago" --no-pager
sudo tail -n 200 /var/log/mail.log

If you need a clean SMTP setup with SPF/DKIM/DMARC (strongly recommended in 2026), follow: SMTP setup tutorial and then verify DNS with SPF/DKIM/DMARC setup guide.

Step 4: Run a manual report and verify the sections you care about

Before you schedule anything, generate a report to stdout. Then confirm it shows the signals you expect: SSH failures, sudo activity, cron errors, web server issues, and more.

sudo logwatch --range yesterday --detail med --output stdout

If you run Nginx and don’t see an Nginx section, make sure Logwatch can read the logs. Typical paths are:

• /var/log/nginx/access.log
• /var/log/nginx/error.log

If your server uses a custom log layout (common with some panels or hardened builds), you may need service overrides under /etc/logwatch/conf/services/. Keep overrides small and targeted. Most Ubuntu installs work without extra tuning.

Step 5: Tune noise vs signal (the only way Logwatch stays useful)

Internet-facing servers generate a steady stream of “bad-looking” events. Many of them are not incidents. Don’t chase a perfect report.

Aim for a report you’ll actually read every day.

Adjust the detail level first

Start with Detail = Med. If the report feels too thin, bump it to High. If it turns into a wall of text, drop to Low and tighten services.

Edit your config:

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

Limit to hosting-relevant services

Every extra service pushes the important items further down. For a WordPress/PHP hosting VPS, this set usually covers the daily essentials:

• sshd: login attempts, invalid users, key failures
• sudo: privilege escalation events
• cron: failing scheduled jobs (backups, renewals)
• ufw or firewall logs: scan bursts, blocked ports
• fail2ban: bans and repeat-offender patterns
• nginx or apache: error spikes, suspicious URIs

If you run a control panel like cPanel/WHM, you may also want FTP/IMAP/POP summaries. Add those later. First, confirm the “core” report stays short enough to scan.

Common hosting signals to look for (and what to do next)

• Repeated “Invalid user” SSH attempts: tighten SSH and add IP allowlists. If you haven’t, use the Fail2Ban setup tutorial.
• Spikes in 404s to WordPress endpoints (/wp-login.php, /xmlrpc.php): rate limit at Nginx and block obvious offenders. HostMyCode has a focused guide: Nginx rate limiting tutorial.
• Growing auth.log: often just background internet noise. Treat it as baseline data, and watch for sudden shifts.
• Cron errors: fix these quickly. Cron failures often mean backups, renewals, or maintenance jobs stopped running.

Step 6: Schedule the daily report (cron) and confirm timing

On Ubuntu, Logwatch often installs a daily cron job under /etc/cron.daily/. Check for it:

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

If it exists, your main work is usually just /etc/logwatch/conf/logwatch.conf. If it doesn’t exist, create a dedicated cron entry. This keeps the timing explicit:

sudo nano /etc/cron.d/logwatch

Example: run daily at 06:25 server time:

# /etc/cron.d/logwatch
25 6 * * * root /usr/sbin/logwatch

To confirm everything works end-to-end, run it once manually:

sudo /usr/sbin/logwatch

Step 7: Add a “red flag” checklist for fast triage

When the email arrives, scan these sections first. You can usually triage the whole report in under a minute.

1. SSHD: any successful root login? any logins at odd hours from new IPs?
2. sudo: unexpected commands or unknown users?
3. fail2ban: sudden ban spikes (attack in progress, or an allowlist mistake)?
4. web server: repeated 500/502/504 errors or sudden error bursts?
5. cron: failures that suggest backups, renewals, or maintenance jobs broke?

If something looks off, work the problem in order. Confirm the time window first. Identify source IPs next. Then block or rate-limit.

Pair Logwatch with a firewall ruleset that matches hosting reality (SSH + HTTP/S only). For a solid baseline, use: UFW firewall setup tutorial.

Step 8: Hardening the report itself (reduce risk, improve deliverability)

Logwatch emails often include usernames, IP addresses, and request paths. That’s expected. It’s also sensitive operational data.

Treat these reports like admin logs, not casual notifications.

• Send to a restricted mailbox (not a shared inbox) and enable MFA.
• Use a stable From address like logwatch@yourdomain and ensure your SPF covers the sending IP.
• Keep MailTo narrow. Start with one address. Add more only if you have an on-call rotation.

If you manage multiple VPS instances, use distinct MailFrom values or subject prefixes. That makes it easier for filters to label reports automatically.

Step 9: Troubleshooting (what to check when the report is missing or empty)

No email arrives

• Verify cron ran: grep -i logwatch /var/log/syslog | tail (Ubuntu often logs cron to syslog).
• Verify local mail queue: mailq (Postfix) and inspect bounces.
• Check outbound SMTP blocks or missing rDNS/SPF.

For rDNS setup on VPS/dedicated servers, use: reverse DNS setup guide. If your emails land in spam, walk through: email deliverability troubleshooting.

The report is empty or missing key sections

• Confirm logs exist in /var/log (or that your service writes there).
• Check permissions (Logwatch runs as root from cron; manual runs as your user may see less).
• If you rely on journald-only logs for a service, you may need to enable file logging for that daemon.

The report is too long to read

• Drop Detail from Med to Low.
• Reduce services to the essentials. Add one service per week until it stays readable.
• Address the root cause: heavy bot traffic should be rate-limited or blocked, not summarized forever.

Step 10: Pair Logwatch with backups and restore drills (hosting reality)

Logwatch tells you what changed. Backups let you recover when something breaks anyway.

If you don’t have tested backups, fix that before you spend time polishing reports. Start here: VPS backup setup guide tutorial. If you want a practical “server is dead, rebuild fast” runbook, use: VPS disaster recovery tutorial.

Summary: a daily report that pays for itself

Once scheduled and tuned, Logwatch gives you a short daily email. It answers three questions: who tried to get in, what broke, and what changed. That’s the baseline you want on any hosting VPS, especially if it runs multiple client sites or a busy WordPress install.

If you’re building or migrating hosting infrastructure in 2026, start with a predictable foundation. Add visibility early. Clean logging plus reliable email delivery makes this workflow boring—in the best way.

For predictable performance and admin control, run this on a HostMyCode VPS. If you’d rather reduce maintenance overhead (updates, security defaults, and hands-on help), managed VPS hosting is the practical option.

FAQ

Does Logwatch replace monitoring and alerts?

No. Logwatch is a daily summary, not a real-time alerting system. It complements monitoring by surfacing patterns and slow-burn issues that are easy to miss in dashboards.

Should I run Logwatch on a shared hosting plan?

Usually not. Shared hosting rarely gives you root-level access to system logs or cron at this level. Logwatch fits VPS or dedicated servers where you control /var/log and mail delivery.

What’s the best time to schedule the Logwatch email?

Pick a quiet hour after log rotation completes. Early morning server time (for example, 06:00–07:00) is a common choice.

My Logwatch emails go to spam. What should I fix first?

Start with SPF, DKIM, and DMARC for the sending domain, then verify reverse DNS for the server IP. Keep the From address consistent, and avoid changing hostnames frequently.

Can I get separate reports per domain (virtual host) on Nginx/Apache?

Logwatch summarizes per service, not per site. If you need per-domain reporting, you’ll typically add per-vhost access-log analysis or ship logs to a central system. For many VPS admins, a single daily service-level report is the right balance.