Enabling error logging

When something on your site is misbehaving, the error log usually has the answer. Make sure logging is on, know where to look.

Where logs live

We capture multiple types of logs:

PHP errors

By default, PHP errors are logged but not displayed (suppressed from output, sent to log file).

• Per-account log: /home/your-user/logs/error_log — all PHP errors for your hosting account.
• Per-domain log: /home/your-user/logs/_error_log — errors specific to one domain.
• In cPanel: under Metrics → Error Log, viewable in browser.

Access logs

Web server access logs (every request that hit your site):

• Per-domain access log: /home/your-user/logs/_access_log.
• In cPanel: Raw Access Logs.

These show every request your site got — useful for traffic analysis or identifying attack patterns.

Database logs

Slow query log (queries taking longer than threshold):

• Available on cPanel via MySQL slow query reports.
• Or via SSH if your plan supports.

WordPress debug log

If you've enabled WP_DEBUG_LOG:

• File: /wp-content/debug.log in your WordPress install.
• Viewable via FTP or file manager.

Enable PHP error logging

Almost always already on. If not:

1. Edit php.ini settings via Services → PHP → Edit PHP options.
2. Set:
   • log_errors = on
   • error_log = /home/your-user/logs/error_log

Save. Logging starts immediately.

Display errors during development

For local development or staging, you can show errors in the browser instead of (or in addition to) logging:

display_errors = on
display_startup_errors = on
error_reporting = E_ALL

Don't enable display_errors in production — error messages can leak sensitive paths and configuration to attackers.

For per-script display while debugging, add to the top of the script:

ini_set('display_errors', 1);
error_reporting(E_ALL);

Remove when done debugging.

Enable WordPress debug logging

In wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This:

• Turns on WordPress's internal error reporting.
• Logs to /wp-content/debug.log.
• Doesn't show errors in the browser (production-safe).

After triggering the issue, read /wp-content/debug.log for what went wrong.

Turn off when done:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);

Read the logs

In cPanel:

1. Open cPanel → Metrics → Error Log.
2. Recent errors appear, newest first.
3. Search for keywords (your domain, the URL that failed, etc.).

Via FTP:

1. Open File Manager → navigate to /home/your-user/logs/.
2. Open error_log.
3. Recent entries are at the bottom.

Via SSH (plans with shell access):

tail -f /home/your-user/logs/error_log

Live streaming as new errors come in. Useful while reproducing an issue.

Log levels

PHP error levels in increasing severity:

• Notice — minor things (undefined variable used).
• Warning — something's wrong but execution continues.
• Error — execution stopped.
• Fatal Error — execution stopped immediately, no recovery.
• Exception — uncaught exception.

In production, you want at least Errors and Fatal Errors logged. Notices and Warnings can clutter logs but help during development.

Log rotation

Logs grow. We rotate them automatically:

• Daily rotation — logs older than the current day are renamed (error_log.1, error_log.2, etc.).
• 30-day retention — older rotated logs are deleted.

If you need longer retention, copy logs off-server periodically (rsync to a backup machine, off-site storage).

Common log entries you'll see

• PHP Notice: Undefined variable: foo in /path/script.php on line 23 — code uses an unset variable. Often harmless but worth fixing.
• PHP Warning: include(...)/wrapper failed to open stream: No such file or directory — file path is wrong; the include can't be found.
• PHP Fatal error: Uncaught Error: Call to undefined function foo() — a function that doesn't exist is being called.
• mod_security: Access denied with code 403... — ModSecurity blocked the request as suspicious.
• mod_evasive: ... — DDoS-protection module rate-limited an IP.

The path and line number tell you exactly where to look in your code.

Power-user note

For complex applications, structured logging (JSON-formatted entries with metadata) makes log analysis much easier than text logs. Tools like Monolog (PHP), structlog (Python) write JSON; combined with a log analysis service (Loggly, Papertrail, Sumo Logic) you get searchable, filterable logs.

For most hosting users, the cPanel error log is enough. Structured logging is worth setting up for active development of complex applications.