Reading the error log before you open a ticket

Most tickets that begin "my site is broken" are answered by a line already sitting in that account's error log. Reading it first turns a day of waiting into ten minutes, and when you do open a ticket, pasting the line gets you a real answer instead of a request for more information.

The three logs and what each answers

• PHP error log: why the application failed. Fatal errors, undefined functions, memory exhaustion, database connection failures. This is the one to read first for a blank page or a 500.
• Web server error log: why the request never reached the application. Permission problems, rewrite loops, missing files, malformed directives.
• Access log: who asked for what, and what they got back. This is for traffic questions, not for errors.

Matching the symptom to the right log is most of the skill. A white screen is almost always the PHP log. A 403 is almost always the web server log.

Read the bottom, not the top

Logs append. The line you want is the most recent one, and the file may contain months of noise above it. Note the time the problem happened and read backwards from there.

tail -n 50 ~/logs/error_log
grep -i "fatal" ~/logs/error_log | tail -n 20

If you are working through the file manager rather than a shell, open the log and jump to the end. Reading from the top wastes time on errors that were fixed long ago.

What common lines actually mean

• Allowed memory size exhausted: one operation needed more memory than the ceiling allows. Usually an import, an image operation or a plugin doing something large. Not general load.
• Maximum execution time exceeded: something ran too long. Look at what it was doing rather than raising the limit.
• Error establishing a database connection: credentials or the database itself. Very often follows a site being moved between accounts, because the user name prefix changed.
• Permission denied: file ownership or mode, frequently after files were uploaded by a different method than usual.
• File does not exist: a request for something genuinely absent. Often just bots probing, not a fault.

That last one fills logs with noise on every public site. Learn to skip it so it does not hide the real line.

Errors with no visitors

If the log fills up while the site has no traffic, something is running on its own: a cron job, a plugin doing background work, or an integration polling. This is the same signature that shows up as resource faults with a low average, described in Platform and Limits. The log tells you which script; the fault counter told you it was happening.

On a network, compare rather than read

With many sites, the useful question is not "what does this log say" but "does this site's log look like the others". A single site erroring is that site. Every site erroring at once is usually something you did to all of them, or the same plugin updated everywhere.

Checking two or three sibling sites before concluding anything saves you from investigating one site for a problem that belongs to the whole estate.

When you do open a ticket

Include the exact error line, the time it happened, and what you changed most recently. That turns a diagnostic conversation into a fix. Never include passwords or tokens, as noted on our contact page.

The log locations are documented at docs.cpanel.net. For narrowing down a fault before you reach the logs, see Diagnostics.