Configure Logwatch Daily Digests on cPanel Servers

Why Log Summaries Matter on a Busy cPanel Server

Raw server logs are not something most hosting customers read voluntarily. A cPanel server running dozens of domains generates megabytes of Apache, mail, SSH, and FTP activity every day. Logwatch solves the practical problem: it distills all of that into a readable daily email you can actually act on.

This guide walks you through installing Logwatch on a cPanel-managed server, configuring Logwatch daily digests on cPanel servers to land in your inbox each morning, and tuning the report so it tells you what matters instead of burying you in noise. The steps apply to both AlmaLinux 8/9 and CloudLinux — the two platforms cPanel most commonly runs on in 2026.

What Logwatch Actually Does

Logwatch reads system log files — /var/log/messages, /var/log/secure, /var/log/maillog, Apache logs, and others — and produces a structured summary. It is not a real-time monitor. Think of it as a morning briefing: failed SSH logins overnight, mail delivery errors, disk warnings, cron failures.

On a cPanel server, it integrates cleanly because cPanel's log structure is standard enough that Logwatch's built-in service filters pick it up without custom scripting. You get useful output from the first run.

If you manage multiple client sites on a single VPS or dedicated server, that daily digest also works as a lightweight audit trail — handy when a client asks why their site was slow last Tuesday or whether any unusual login attempts occurred.

Before You Start: Hosting Environment Checks

A few quick checks before installing anything:

• Root SSH access — Logwatch installs via the system package manager and runs as root. You need full shell access.
• Outbound mail working — Logwatch sends its digest by email. If Postfix or Exim (cPanel's default MTA) is misconfigured, digests will queue silently. Test with echo "test" | mail -s "test" you@yourdomain.com before proceeding.
• Firewall not blocking loopback — Logwatch sends to localhost first; this is almost never an issue, but worth knowing if email delivery fails after setup.

If you are running a Hostperl VPS with cPanel, SSH access is available from the moment your server is provisioned. No additional configuration is needed to follow this guide.

Installing Logwatch on AlmaLinux or CloudLinux

Logwatch is in the default EPEL and base repositories. On AlmaLinux 8 or 9:

dnf install logwatch -y

On CloudLinux (which shares the RHEL 7/8 base depending on version):

yum install logwatch -y

After installation, confirm it is present:

logwatch --version

You should see output like Logwatch 7.x. The main configuration directory is /etc/logwatch/, and the default configuration file lives at /usr/share/logwatch/default.conf/logwatch.conf. Do not edit that file directly — copy it to the local override location instead:

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

Now you have a local copy that survives package updates.

Configuring Logwatch for cPanel: Core Settings

Open your local config file:

nano /etc/logwatch/conf/logwatch.conf

The settings that matter most for a cPanel hosting environment:

# Where to send the digest
MailTo = admin@yourdomain.com

# Send from this address
MailFrom = logwatch@yourhostname.com

# Detail level: Low, Med, High
Detail = Med

# Range: Yesterday covers the prior 24-hour period
Range = yesterday

# Output format: mail
Output = mail

# Format: text is cleaner for email clients
Format = text

Start with Detail = Med. High-detail reports on a busy server can run to hundreds of lines, most of them routine. You can raise the level for specific services later if you need more granularity.

The Range = yesterday setting ensures the digest covers exactly the prior day when triggered by a 6 AM cron job — which is the behaviour you want.

Scheduling the Daily Digest with Cron

Logwatch ships with a cron file at /etc/cron.daily/0logwatch on most systems. Check whether it already exists:

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

If it is present, Logwatch will run automatically as part of the daily cron sweep, usually between 3–6 AM depending on your anacron configuration. That is fine for most setups.

If you want a specific delivery time — say, 7 AM so the report lands before your working day — add a dedicated cron entry instead:

crontab -e

Add:

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

If you use the dedicated entry, remove the default daily file to avoid duplicate reports:

chmod -x /etc/cron.daily/0logwatch

Filtering Out cPanel-Specific Noise

By default, Logwatch reports on every service it finds log files for. On a cPanel server this often includes cphulkd (cPanel's brute-force protection), cPanel update logs, and various internal daemons. The volume is manageable, but a few services generate repetitive entries that add little value.

To suppress a service from reports, create a filter override file. To silence cphulkd entries:

mkdir -p /etc/logwatch/conf/services/
nano /etc/logwatch/conf/services/cphulkd.conf

Add:

$ignore_services = cphulkd

Alternatively, pass --service All --service '-cphulkd' in your cron command if you prefer inline control over config files.

The services that produce genuinely useful signal on a cPanel server are: sshd (failed logins), postfix or exim (mail delivery), http (Apache 404s and errors), disk_space, and pam. Start there.

For a more complete picture of day-to-day server health, pair Logwatch with scheduled disk usage alerts — see the Hostperl guide on monitoring disk usage with automated alerts for a complementary setup.

Testing Your Configuration Before Going Live

Run Logwatch manually and print to the terminal before trusting the cron job:

logwatch --output stdout --detail Med --range yesterday

This lets you check the report content without waiting for email delivery. Scan for the sections you care about — SSH authentication attempts, mail queue activity, Apache errors.

Then run a full email test:

logwatch --output mail --mailto admin@yourdomain.com --detail Med --range yesterday

Verify the email arrives, that it does not land in spam (if it does, check your SPF/DKIM setup — the Hostperl guide on Postfix SPF authentication covers the fundamentals), and that the formatting is readable in your mail client.

Sending Digests to Multiple Recipients

If you manage a server for multiple clients or work with a small team, you can distribute the digest to multiple addresses. Logwatch does not natively support multiple MailTo values in a single entry, but there are two clean workarounds.

Option 1 — create a distribution alias in cPanel's mail routing. Set up a local alias like server-logs@yourdomain.com that forwards to all recipients, then use that as your single MailTo value.

Option 2 — run multiple cron entries with different --mailto flags. Less elegant, but it gives you per-recipient detail-level control if your team has varying technical backgrounds.

Reading the Digest: What to Actually Look For

A well-configured digest is short enough to read in two minutes. Here is what each key section means in practice:

• sshd section — Look for high volumes of failed logins from unfamiliar IPs. More than 50–100 failures overnight is worth investigating. Pair this with Fail2Ban jails to block repeat offenders automatically.
• Disk space section — Any partition above 85% deserves attention before it becomes a problem. cPanel servers accumulate mail queues and log files faster than most people expect.
• HTTP/Apache section — A spike in 404 or 500 errors often points to a broken plugin, a failed migration, or a bot scanning for vulnerabilities.
• Postfix/Exim section — Delivery failures, relay rejections, or bounce spikes can flag a compromised account before it damages your domain reputation.

If the Exim mail queue is growing faster than expected, the Hostperl article on cPanel email queue management covers how to diagnose and clear backlogs.

Keeping Reports Useful Over Time

Reports go stale when you stop reading them. A few habits keep them actionable:

• Review the detail level every few months. If you have never seen a warning in a given section, either the service is healthy or the detail level is too low — check both before muting it.
• When you add new services to the server (a new mail domain, a new cron job, a new application), check whether Logwatch picks them up and whether they add useful signal or just noise.
• If a section suddenly inflates — hundreds of lines where there were dozens before — treat that as an alert in itself. Something changed.

Frequently Asked Questions

Will Logwatch conflict with cPanel's own monitoring tools?

No. Logwatch reads log files passively — it does not intercept or modify them. cPanel's cphulkd, CSF, and built-in log views operate independently. You can run all of them together without conflict.

My Logwatch email is going to spam. How do I fix it?

The most common cause is a missing or mismatched SPF record for the server's hostname, or Exim/Postfix sending from an address not covered by your domain's SPF policy. Set MailFrom to an address on a properly configured domain and verify your SPF/DKIM records are in place.

How do I change the report's date range to cover the last 7 days?

Set Range = -7 in your config file, or pass --range "-7 days" on the command line. Weekly summaries work well for low-traffic servers where daily reports would be very sparse.

Can I get Logwatch reports for a specific service only?

Yes. Pass --service sshd (or any service name) in your cron command or test run. Chain multiple services like this: --service sshd --service http.

Logwatch says "no log data found" for some services. Why?

The log file path probably does not match what Logwatch expects. cPanel sometimes writes logs to non-standard locations. Check the service config under /usr/share/logwatch/default.conf/services/ and verify the LogFile directive points to where cPanel actually writes logs on your system.