cPanel & WHM Log Files: The Complete Technical Reference for Server Administrators

cPanel & WHM maintains a comprehensive, multi-layered logging architecture that records every significant event across web services, mail delivery, authentication, databases, and system operations. Each log file has a distinct location, format, and diagnostic purpose — knowing which log to consult and how to parse it efficiently is the difference between a five-minute fix and a multi-hour outage investigation.

This guide covers every critical log file in a production cPanel & WHM environment, including file paths, log formats, real-world diagnostic use cases, and command-line techniques that experienced sysadmins actually use.

Why cPanel & WHM Log Files Demand Your Attention

Log files are not just an audit trail — they are the primary diagnostic instrument for any Linux-based hosting stack. In a cPanel environment specifically, the logging surface spans Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk, and the cPanel/WHM application layer itself.

Administrators who treat logs reactively — checking them only after a failure — consistently miss early warning signals: gradual memory exhaustion, incremental brute-force campaigns, slow query accumulation, and certificate-related delivery failures. Proactive log analysis catches these patterns before they become incidents.

Three core operational goals drive log analysis in cPanel environments:

• Root-cause diagnosis: Correlating timestamps across Apache, PHP, and MySQL logs to pinpoint the exact failure point in a request chain.
• Performance baselining: Identifying slow queries, high-latency HTTP responses, and resource-hungry processes before they saturate server capacity.
• Security forensics: Reconstructing attack timelines from SSH auth logs, cPHulk records, and Exim reject logs to determine scope and remediation steps.

Apache Log Files

Apache is the default web server in cPanel environments, though LiteSpeed is increasingly common as a drop-in replacement. Both write logs in compatible formats to the same conventional paths.

Apache Error Log

Location: /usr/local/apache/logs/error_log

This is the single most consulted log in any cPanel troubleshooting session. It captures every error Apache generates: PHP fatal errors (when PHP runs as a module), .htaccess syntax failures, mod_rewrite rule mismatches, permission denials, SSL handshake failures, and upstream proxy errors.

A critical detail that many guides omit: per-domain error logs also exist and are often more immediately useful than the global error log. They are located at:

/home/username/logs/domain.com-ssl_error_log
/home/username/logs/domain.com-error_log

These per-VirtualHost logs isolate errors to a single account, dramatically reducing noise when you are diagnosing one specific site on a shared server.

Common diagnostic pattern — .htaccess rewrite loop:

grep "RewriteRule" /usr/local/apache/logs/error_log | tail -50

Common diagnostic pattern — PHP fatal errors by domain:

grep "PHP Fatal" /home/username/logs/domain.com-error_log | tail -30

Apache Access Log

Location: /usr/local/apache/logs/access_log

The global access log records every HTTP/HTTPS request in Combined Log Format by default:

IP - username [timestamp] "METHOD /path HTTP/version" status_code bytes_sent "referer" "user_agent"

Per-domain access logs are stored at /home/username/logs/domain.com-access_log and are the correct source for traffic analysis on individual accounts.

Practical use cases:

• Identifying a DDoS or scraping campaign by IP frequency:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

• Finding all 500-series errors in the last hour (requires log timestamps to be recent):

grep " 5[0-9][0-9] " /usr/local/apache/logs/access_log | tail -200

• Detecting vulnerability scanners by user-agent string:

grep -i "sqlmap|nikto|masscan|nmap" /usr/local/apache/logs/access_log

Edge case: On servers with piped logging enabled in WHM, the access log may be empty or minimal because logs are being piped directly to a log processing daemon. Check WHM > Apache Configuration > Global Configuration for the CustomLog directive if you find an unexpectedly empty access log.

Apache SSL/TLS Log

Location: /usr/local/apache/logs/ssl_error_log

This log captures TLS negotiation failures, certificate validation errors, and cipher suite mismatches. It is essential when debugging HTTPS connectivity issues that do not appear in the main error log. Look here first when users report browser SSL warnings or when automated certificate renewal via AutoSSL fails silently.

cPanel and WHM Application Logs

cPanel Access Log

Location: /usr/local/cpanel/logs/access_log

Records every HTTP request made to the cPanel interface (port 2082/2083). Each entry includes the authenticated username, the action performed, and the originating IP. This log is the primary source for auditing what a specific user did inside their cPanel account.

Find all actions performed by a specific user:

grep "username" /usr/local/cpanel/logs/access_log | grep -v "GET /favicon"

cPanel Error Log

Location: /usr/local/cpanel/logs/error_log

Captures internal errors from the cPanel application layer — failed API calls, broken cPanel plugins, Perl script errors in cPanel's backend, and template rendering failures. If the cPanel interface is throwing 500 errors or specific features are broken, this is the first log to check.

WHM Login Log

Location: /usr/local/cpanel/logs/login_log

Records all WHM authentication events — successful logins, failed attempts, two-factor authentication challenges, and API token usage. This log is critical for detecting unauthorized administrative access.

Find all failed WHM login attempts:

grep "FAILED" /usr/local/cpanel/logs/login_log | awk '{print $NF}' | sort | uniq -c | sort -rn

cPHulk Brute Force Protection Log

Location: /usr/local/cpanel/logs/cphulkd.log

This is a log that most guides skip entirely, yet it is one of the most operationally important. cPHulk is cPanel's built-in brute-force protection daemon. It monitors SSH, FTP, cPanel, and WHM login attempts and automatically blocks IPs that exceed threshold limits.

When a legitimate administrator is locked out of WHM or SSH, the answer is almost always in this log. You can also query the cPHulk database directly:

mysql -u root cphulkd -e "SELECT ip, user, type, timestamp FROM brutes ORDER BY timestamp DESC LIMIT 20;"

To unblock a specific IP from the command line:

/usr/local/cpanel/bin/cphulk_pam_ctl --unblock=192.168.1.1

cPanel Update and Install Log

Location: /var/cpanel/updatelogs/

Each cPanel update run generates a timestamped log file in this directory. When a cPanel upgrade breaks a service or a feature disappears after an update, this directory contains the full output of the update process, including any errors that occurred during package installation or configuration migration.

ls -lt /var/cpanel/updatelogs/ | head -5

Email Log Files

Email is consistently the most complex subsystem to troubleshoot in cPanel. Exim, cPanel's default MTA, generates three separate log streams, each serving a distinct diagnostic purpose.

Exim Main Log

Location: /var/log/exim_mainlog

This is the primary email transaction log. Every message that Exim processes — inbound or outbound — generates entries here covering acceptance, routing decisions, delivery attempts, and final disposition (delivered, deferred, or bounced).

Log entry anatomy:

2024-01-15 14:23:01 1rPqXY-0003aB-Kc <= sender@example.com H=mail.example.com [203.0.113.10] P=esmtps S=4821 id=<abc123@example.com>
2024-01-15 14:23:02 1rPqXY-0003aB-Kc => recipient@domain.com R=virtual_user_delivery T=virtual_userdelivery_pipe
2024-01-15 14:23:02 1rPqXY-0003aB-Kc Completed

The message ID (1rPqXY-0003aB-Kc) is the key to tracing a single message through the entire log:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog

Trace all outbound mail from a specific account (critical for spam investigation):

grep "U=username" /var/log/exim_mainlog | grep "<=" | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Real-world edge case: When a compromised WordPress installation is sending spam, the Exim main log will show the sending user as nobody (the Apache process user) rather than a cPanel account username. Filter for this specifically:

grep "U=nobody" /var/log/exim_mainlog | grep "<=" | tail -50

Exim Reject Log

Location: /var/log/exim_rejectlog

Records all messages that Exim refused to accept at the SMTP connection stage — before they were even queued. Rejections occur due to RBL blacklist hits, SPF/DKIM/DMARC failures, invalid HELO strings, relay denial, or rate limiting.

This log is essential for two scenarios: diagnosing why legitimate inbound mail is being rejected, and auditing the effectiveness of your spam filtering rules.

Find the most common rejection reasons:

grep "rejected" /var/log/exim_rejectlog | grep -oP "(?<=: ).*" | sort | uniq -c | sort -rn | head -10

Exim Panic Log

Location: /var/log/exim_paniclog

The panic log captures fatal Exim errors — configuration file parse failures, inability to bind to port 25, database connection failures, and TLS library errors. If this file is non-empty, Exim has experienced a critical failure. In many cases, a non-empty panic log means the mail queue has stopped processing entirely.

# Check if the panic log has content — a non-zero exit means there are critical errors
[ -s /var/log/exim_paniclog ] && echo "CRITICAL: Exim panic log has entries" && tail -20 /var/log/exim_paniclog

Dovecot Log

Location: /var/log/dovecot.log (and /var/log/dovecot-info.log for informational events)

Dovecot handles IMAP and POP3 connections in cPanel environments. Authentication failures, connection limits, mailbox locking issues, and quota enforcement events all appear here. When users cannot connect to their email client, Dovecot's log is the correct place to look — not Exim.

grep "auth failed" /var/log/dovecot.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

Database Log Files

MySQL/MariaDB Error Log

Location: /var/lib/mysql/$(hostname).err

This log records MySQL/MariaDB startup and shutdown events, InnoDB recovery operations, replication errors, table corruption warnings, and any query that causes a server-level error. It is the definitive source for diagnosing database crashes and unexpected restarts.

Retrieve the actual path dynamically:

mysql -u root -e "SHOW VARIABLES LIKE 'log_error';"

Check for InnoDB corruption or crash recovery events:

grep -i "crash|corrupt|recovery|innodb" /var/lib/mysql/$(hostname).err | tail -30

MySQL Slow Query Log

Location: /var/lib/mysql/slowquery.log (when enabled)

The slow query log is disabled by default in most cPanel installations. Enabling it is one of the highest-value performance tuning actions you can take on a database-heavy server.

Enable the slow query log at runtime (no restart required):

mysql -u root -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/lib/mysql/slowquery.log';"

Once enabled, use mysqldumpslow to aggregate and rank the worst offenders:

mysqldumpslow -s t -t 10 /var/lib/mysql/slowquery.log

This outputs the top 10 queries by total execution time — the most actionable starting point for query optimization.

Critical nuance: A long_query_time of 1 second is a reasonable starting threshold for most applications, but high-traffic sites should consider 0.5 seconds or even 0.25 seconds to catch queries that are individually fast but cumulatively expensive under load.

MySQL General Query Log

Location: Configurable, typically /var/lib/mysql/general.log

The general query log records every single SQL statement sent to the server. Do not enable this in production without a specific, time-limited diagnostic reason. On a busy server, this log can grow at gigabytes per hour and will itself cause performance degradation. Enable it briefly, reproduce the issue, then disable it immediately.

mysql -u root -e "SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/var/lib/mysql/general.log';"
# ... reproduce the issue ...
mysql -u root -e "SET GLOBAL general_log = 'OFF';"

System Log Files

System Messages Log

Location: /var/log/messages

The kernel and system daemon message log. Hardware errors (disk I/O failures, memory ECC errors), OOM (Out of Memory) killer events, network interface state changes, and kernel module loading events all appear here. This is the first log to check when a server becomes unresponsive or reboots unexpectedly.

Check for OOM killer events (a server silently killing processes due to memory exhaustion):

grep -i "oom|killed process|out of memory" /var/log/messages | tail -20

Check for disk I/O errors that may indicate drive failure:

grep -i "I/O error|blk_update_request|ata.*error" /var/log/messages | tail -20

Secure Authentication Log

Location: /var/log/secure

Records all PAM-based authentication events: SSH logins (successful and failed), sudo command execution, su attempts, and cron-initiated authentication. This is the primary log for SSH security forensics.

Identify the top attacking IPs by failed SSH login count:

grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

Audit all sudo commands executed on the server:

grep "sudo:" /var/log/secure | grep "COMMAND" | tail -50

Real-world edge case: On servers with UseDNS yes in sshd_config, failed login entries may show hostnames instead of IP addresses, which breaks the IP-extraction awk pattern above. Verify your sshd_config setting and adjust the field index accordingly.

Kernel Ring Buffer

Location: Runtime only — accessed via dmesg

The kernel ring buffer is not a persistent file but is essential for diagnosing hardware-level events that occur at or shortly after boot, before syslog initializes. On systemd-based systems (CentOS 7+, CloudLinux 7+), persistent kernel logs are available via:

journalctl -k --since "1 hour ago"

FTP Log Files

ProFTPd Log

Location: /var/log/proftpd/proftpd.log

ProFTPd is the default FTP daemon in cPanel environments. This log records all FTP session events: authentication attempts, directory traversal, file uploads, downloads, and disconnections.

Find all failed FTP login attempts:

grep "USER|PASS" /var/log/proftpd/proftpd.log | grep -i "failed|incorrect" | tail -30

Identify large file uploads (potential malware staging):

grep "STOR" /var/log/proftpd/proftpd.log | awk '{print $NF, $0}' | sort -rn | head -20

Pure-FTPd Log

Location: /var/log/pureftpd.log

Pure-FTPd logs are written to syslog by default on some configurations, which means entries may appear in /var/log/messages rather than a dedicated file. Verify the active logging destination:

grep "VerboseLog|AltLog" /etc/pure-ftpd.conf

PHP and Application-Level Logs

PHP Error Log

PHP errors in cPanel environments can be logged in multiple locations depending on the PHP handler in use:

The PHP-FPM pool log path includes the PHP version number. For PHP 8.2 managed by EasyApache 4:

tail -f /opt/cpanel/ea-php82/root/usr/var/log/php-fpm/error.log

Per-account PHP error logging can be enabled by adding the following to the account's php.ini or .htaccess:

log_errors = On
error_log = /home/username/logs/php_errors.log

cPanel-Specific Service and Security Logs

cPanel Service Manager Log

Location: /usr/local/cpanel/logs/safeapacherestart_log

Records every Apache restart event triggered by cPanel's service manager, including the reason for the restart and whether it succeeded. Useful for correlating Apache downtime with configuration changes.

cPanel Backup Log

Location: /usr/local/cpanel/logs/cpbackup/

Each backup run generates a per-account log file in this directory. When a backup fails silently, this directory contains the specific error — whether it was a disk space issue, a database dump failure, or a permissions problem.

ls -lt /usr/local/cpanel/logs/cpbackup/ | head -10
grep -i "error|fail" /usr/local/cpanel/logs/cpbackup/username.log

cPanel AutoSSL Log

Location: /var/cpanel/logs/autossl/

AutoSSL is cPanel's automated Let's Encrypt / Sectigo certificate provisioning system. When SSL certificate renewal fails, the detailed reason — DCV failure, rate limiting, domain validation mismatch — is recorded here. This log is critical for diagnosing HTTPS certificate expiry issues before they cause browser warnings.

ls -lt /var/cpanel/logs/autossl/ | head -5
tail -100 /var/cpanel/logs/autossl/$(ls -t /var/cpanel/logs/autossl/ | head -1)

If you manage SSL certificates across multiple domains or need certificates beyond what AutoSSL provides, SSL Certificates from a dedicated provider offer extended validation and wildcard options that Let's Encrypt does not.

Log File Comparison Reference

Command-Line Log Analysis Techniques

Essential Commands for Real-Time and Historical Analysis

Follow a log in real time (the most common sysadmin workflow):

tail -f /var/log/exim_mainlog

Follow multiple logs simultaneously using multitail (install via yum install multitail):

multitail /usr/local/apache/logs/error_log /var/log/exim_mainlog

Extract and count unique values from a specific field:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

Search across compressed rotated log archives:

zgrep "keyword" /var/log/exim_mainlog.*.gz

Filter log entries within a specific time window:

awk '/15/Jan/2024:14:00/,/15/Jan/2024:15:00/' /usr/local/apache/logs/access_log

Count HTTP status code distribution:

awk '{print $9}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn

Log Rotation in cPanel

cPanel uses logrotate to manage log file sizes. The rotation configuration for cPanel-managed logs is in /etc/logrotate.d/. Apache logs are rotated by cPanel's own splitlogs mechanism, which also splits the global access log into per-domain files.

Check the current logrotate configuration for a specific service:

cat /etc/logrotate.d/syslog

Manually trigger log rotation for testing:

logrotate -f /etc/logrotate.d/syslog

Critical pitfall: If log rotation is misconfigured or disk space is exhausted, log files can grow to fill the entire partition, causing all services to fail simultaneously. Monitor disk usage on the partition containing /var/log and /usr/local/apache/logs as a standard operational practice.

Centralized Log Management and Alerting

For production environments — particularly on a VPS Hosting or Dedicated Server — relying on manual log inspection is insufficient at scale. Implement one of the following approaches:

Log aggregation with rsyslog forwarding: Configure /etc/rsyslog.conf to forward logs to a centralized syslog server or a SIEM platform. This preserves logs even if the server itself is compromised.

ELK Stack (Elasticsearch, Logstash, Kibana): Ingest cPanel logs via Filebeat agents, parse them with Logstash pipelines, and visualize patterns in Kibana. This approach enables full-text search across months of log history in seconds.

Fail2ban integration: Fail2ban reads /var/log/secure and /var/log/exim_mainlog and automatically creates iptables rules to block attacking IPs. It operates independently of cPHulk and provides an additional defense layer.

GoAccess for Apache log analysis: GoAccess is a real-time terminal-based log analyzer that produces HTML reports from Apache access logs without requiring a full ELK deployment:

goaccess /usr/local/apache/logs/access_log --log-format=COMBINED -o /var/www/html/report.html

Administrators managing multiple cPanel accounts or reseller setups on a VPS with cPanel benefit significantly from centralized log visibility, since individual account logs are otherwise siloed under each home directory.

Email Infrastructure Log Correlation

One of the most underappreciated diagnostic techniques in cPanel environments is cross-referencing Exim logs with Dovecot logs and the system authentication log to trace the full lifecycle of an email security incident.

Scenario: A user reports their account is sending spam they did not write.

Step 1 — Identify the Exim message IDs associated with the account:

grep "U=username|from=<.*@userdomain.com>" /var/log/exim_mainlog | grep "<=" | head -20

Step 2 — Check if the sending originated from a web application (PHP mail()) or authenticated SMTP:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog | grep -E "P=esmtpa|P=local"

P=esmtpa indicates authenticated SMTP submission. P=local or P=pipe indicates a local script (likely a compromised web application).

Step 3 — If P=esmtpa, find the originating IP from the Dovecot or Exim auth log:

grep "username" /var/log/dovecot.log | grep "Login" | tail -20

Step 4 — Cross-reference that IP against /var/log/secure for SSH activity and against the cPanel access log for control panel logins.

This four-step correlation technique definitively answers whether the compromise was credential theft, a vulnerable web application, or a brute-forced SMTP account — and that distinction determines the remediation path entirely.

For organizations running their own mail infrastructure, a properly configured Email Hosting environment with dedicated log monitoring provides the isolation needed to prevent cross-account mail reputation damage.

Domain and DNS-Related Log Considerations

DNS resolution failures often manifest as errors in application logs rather than in a dedicated DNS log. Named (BIND), which cPanel uses for DNS, logs to /var/log/messages by default.

Check for BIND errors:

grep "named" /var/log/messages | grep -i "error|failed|refused" | tail -20

When DNS propagation issues affect newly registered or transferred domains, correlating the BIND log with the cPanel domain configuration helps isolate whether the problem is a zone file error or a registrar-level propagation delay. If you are managing domain registration and DNS through the same platform, Domain Registration with integrated DNS management simplifies this diagnostic chain.

Practical Decision Matrix: Which Log to Check First

Key Technical Takeaways

• Always check per-domain logs first (/home/username/logs/) before the global Apache logs — they contain the same data with dramatically less noise.
• A non-empty /var/log/exim_paniclog is a P1 incident — Exim may have stopped processing the mail queue entirely.
• The cPHulk log at /usr/local/cpanel/logs/cphulkd.log is the correct first stop for any lockout scenario, not /var/log/secure.
• Enable the MySQL slow query log (long_query_time = 1) on any production database server — the performance intelligence it provides is worth the minimal overhead.
• Cross-correlate Exim's P= field with Dovecot auth logs to definitively determine whether a spam incident originated from credential theft or a compromised web application.
• Log rotation misconfiguration is a silent failure mode — a full /var/log partition will crash all services simultaneously with no warning.
• zgrep works on rotated .gz archives — historical log analysis does not require decompressing files manually.
• Centralized log forwarding via rsyslog is the minimum viable security posture for any server handling sensitive data — local logs can be deleted by an attacker who gains root access.

Frequently Asked Questions

Where are cPanel error logs located?

The primary cPanel application error log is at /usr/local/cpanel/logs/error_log. Apache web server errors are at /usr/local/apache/logs/error_log, and per-account PHP errors are in /home/username/logs/domain.com-error_log. Each service maintains its own log file at a distinct path.

How do I trace a specific email message through Exim logs?

Every message Exim processes receives a unique message ID visible in /var/log/exim_mainlog. Run grep "MESSAGE_ID" /var/log/exim_mainlog to retrieve every log entry associated with that message, from acceptance through final delivery or bounce.

Why is my Exim panic log non-empty and what should I do?

A non-empty /var/log/exim_paniclog indicates Exim has encountered a fatal error — typically a configuration parse failure, TLS library issue, or inability to bind to port 25. Read the panic log entries, then check Exim's configuration syntax with exim -bV and verify port 25 is not blocked by another process using ss -tlnp | grep :25.

How do I find which PHP script is sending spam through Apache?

Filter the Exim main log for messages sent by the Apache user: grep "U=nobody" /var/log/exim_mainlog. Then cross-reference the timestamps with Apache access log entries to identify the URL that triggered the mail function. The X-PHP-Originating-Script header (if enabled in php.ini) will also identify the exact script file.

What is the fastest way to check if a server is under a brute-force SSH attack?

Run grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10 to see the top attacking IP addresses by attempt count. Then verify whether cPHulk has already blocked them by checking /usr/local/cpanel/logs/cphulkd.log or querying the cPHulk database directly.