When a website breaks, most owners see the symptom, a blank page, a slow load, or a “500 Internal Server Error”, and start guessing. That guesswork is expensive. The fastest way to find the real cause is to read your website error logs, the running record your server keeps of everything that goes wrong behind the scenes. A log turns “the site is broken” into “PHP ran out of memory on line 214 of a specific plugin file at 09:42”.
Error logs sound intimidating, but they are just text files. Each line records something the server or your CMS tried to do and could not complete. Once you know where the logs live and how to read a single line, you can diagnose a surprising number of problems in minutes.
This guide covers where logs sit across a typical hosting setup, how to read the key parts of an entry, the common messages and what they mean, and a safe workflow for making changes. It also draws a clear line between what you can investigate yourself and what should go straight to your hosting provider.
Where your logs live
There is no single log file. Different layers of your stack keep their own records, and the one you need depends on the problem.
Hosting panel. Most control panels (cPanel, Plesk, etc) expose logs under a “Metrics”, “Logs”, or “Errors” section. This is usually the quickest place to start, because it gathers the web server and PHP errors for your account in one view.
PHP error log. PHP records fatal errors, warnings, and notices here. On many setups it sits in your site root or a logs folder as error_log or php-error.log. The PHP error logging settings control where those messages go. This is the file that names the script and line number that failed.
Web server error log. Apache, Nginx, or LiteSpeed keep their own log, often named error.log. This layer records problems that happen before your application runs: permission failures, missing files, and rewrite issues.
CMS debug log. WordPress can write its own debug.log inside wp-content when debugging is enabled. Other systems have similar application logs. This is useful when a page loads but behaves incorrectly.
Browser and network errors. Some failures never reach the server log because they happen in the visitor’s browser. Open your browser developer tools, then the Console and Network tabs, to see JavaScript errors and failed requests. A resource returning a 404 or a blocked script often explains a broken layout the server logs stay silent about.
If your site is completely offline rather than throwing an error, work through our website down checklist first, then come back to the logs for the detail.
How to read a single log line
A log line packs a lot of information into a short string. Here is a realistic PHP error entry with sensitive values removed:
[25-Jul-2026 09:42:11 UTC] PHP Fatal error: Uncaught Error: Call to
undefined function example_helper() in
/home/site/public_html/wp-content/plugins/example-plugin/core.php:214Read it in parts:
- Timestamp
[25-Jul-2026 09:42:11 UTC]tells you exactly when it happened. Watch the time zone, it may not match yours. Matching this to the moment you saw the problem is the single most useful habit in log reading. - Severity and type
PHP Fatal errormeans execution stopped. Warnings and notices are less severe and often harmless. - Message
Call to undefined functionis the plain-English cause. - File path
/home/site/public_html/wp-content/plugins/example-plugin/core.phppoints at the exact file, and the folder name usually reveals the plugin or theme responsible. - Line number
:214is where it failed inside that file.
Two more things to watch. Repeated entries matter: the same error logged hundreds of times a minute is a live, ongoing fault, while a single entry from last week may be historic. And a web server log adds client and request context, such as the visitor IP and the URL requested, which helps you tell a site-wide fault from one triggered only by a specific page or a bot hammering one endpoint.
Common log messages and what they mean
Once you can parse a line, patterns start to repeat. A handful of message types cover most everyday hosting problems, and each points you toward a different first check.
Quick reference: message, cause, first check
| Log message | Likely cause | First check | When to ask hosting support |
|---|---|---|---|
| PHP Fatal error: Uncaught Error / undefined function | Broken or incompatible plugin, theme, or code | Note the file path and folder name to identify the plugin or theme | If the file is a core server component, not your plugin or theme |
| Allowed memory size of N bytes exhausted | PHP memory limit too low for the task | Check which script triggered it and whether a plugin is the cause | If you cannot raise the limit or it recurs after raising it |
| Permission denied / could not open | Wrong file or folder permissions or ownership | Confirm the file exists and note the path in the message | If ownership is wrong or you cannot correct permissions safely |
| File does not exist / 404 in error log | Missing file, broken link, or bad rewrite rule | Confirm the requested path really should exist | If a server rewrite or config change is needed |
| Error establishing a database connection | Database down, wrong credentials, or overloaded server | Check recent config changes and the CMS database settings | Almost always: database service and server load are host-side |
| 500 Internal Server Error | Many causes; a symptom, not a root cause | Open the PHP and server logs for the matching timestamp | If logs point to server configuration rather than your code |
| Resource limit reached / 508 | Account hit a CPU, memory, or process cap | Check for traffic spikes or a runaway process at that time | Yes: account-level limits are set and monitored by your host |
500 errors and PHP fatal errors
A 500 Internal Server Error is the most misunderstood message on the web. It is not a cause, it is the server’s way of saying “something failed and I cannot show you the page.” The real cause is almost always waiting in the PHP or server error log at the same timestamp.
A PHP fatal error is the classic culprit. The code hit something it could not continue past, then stopped. The log line names the file and line. If the path lands inside wp-content/plugins/ or wp-content/themes/, you have found your suspect. A recent update, a plugin conflict, or a PHP version change is often behind it.
A useful pattern: note the plugin folder from the path, then cross-check it against a broader review of your extensions using our WordPress plugin audit checklist. If the same plugin appears in repeated fatal errors, deactivating it, carefully and with a backup, usually confirms the diagnosis.
Memory limits, permissions and missing files
A memory error looks like this:
[25-Jul-2026 11:03:44 UTC] PHP Fatal error: Allowed memory size of
268435456 bytes exhausted (tried to allocate 20480 bytes) in
/home/site/public_html/wp-content/plugins/example-import/run.php:88PHP was allowed 256MB and ran out. The fix is sometimes a higher limit, but a well-behaved site should not exhaust that much. More often a single plugin, an import, or a report is doing something inefficient, and the file path points you at the task to investigate first.
Permission errors read differently:
[25-Jul-2026 11:14:02 UTC] [error] [client 203.0.113.10]
AH00035: access to /public_html/protected/config.php denied
because search permissions are missing on a component of the pathThis is the web server saying it lacks the rights to read a file. Wrong permissions often appear after a migration, a botched upload, or a restore. Correcting file permissions and ownership is doable for standard files, but ownership problems at the account level are host territory. Do not guess with broad permission changes on server paths you do not control.
Missing file entries are the simplest. A File does not exist line naming an image or script usually means a broken reference, not a server fault. Match it against what your pages actually request. A flood of them for the same odd path is often just a bot probing, which is normal background noise rather than a fault in your site.
Database and cache or plugin issues
“Error establishing a database connection” is one message where you should lean on your host early. Your site could not reach its database. The causes range from wrong credentials after a config edit to the database service being down or overloaded, and the last two are firmly server-side. Check whether you recently changed database settings; if you did not, this is a strong candidate for a support ticket.
Cache and plugin issues are subtler, because the log may look clean while the site misbehaves. A common pattern is a page serving old content after an update, or a fatal error that only appears for logged-out visitors hitting cached routes. If you run a page cache, clearing it is a safe early step, and our LiteSpeed cache guide walks through doing that cleanly on WordPress. When a plugin both writes to the log and stops erroring after deactivation, you have a reliable answer.
Rate and resource limit clues
Some log entries are not about broken code at all, they are about hitting a ceiling. Messages mentioning a resource limit, a 508 error, “too many processes”, or “resources temporarily unavailable” mean your account reached a CPU, memory, or process cap that your host enforces to protect the shared server.
The clue is timing. Line the errors up against your traffic. A spike at a known busy moment, a marketing send, or a bot crawl suggests the limit did its job. Persistent limit errors on modest traffic suggest your plan or setup needs attention, and running your workload on isolated hosting containers can stop a noisy neighbour or a single heavy process from dragging everything down. Either way, resource caps are set and measured on the host side, so the log gives you the evidence and support provides the context.
A safe workflow for changes
Reading a log tells you what went wrong. Acting on it safely is a separate discipline. Rushing a change on a live site can turn a small fault into an outage, so work through these steps in order.
- Reproduce the issue. Load the page or repeat the action that triggers the error, so you know it is live and can confirm any fix.
- Check the exact timestamp. Note the moment it happened and find the matching log line, allowing for the log’s time zone.
- Copy the relevant lines. Save the full entry, path, line number, and message. This is your record and, later, the detail support will want.
- Back up before changes. Take a fresh backup of files and database. A restore point is what separates a quick experiment from a disaster.
- Change one thing at a time. Deactivate a single plugin, or adjust one setting, then stop. Changing several things at once hides which one mattered.
- Retest. Reproduce the original action and check whether the error is gone from the log. If it is, you have your answer. If not, revert and try the next suspect.
- Contact support with useful detail. If it is not resolved, or the log points server-side, raise a ticket with the copied lines, the timestamp, and what you have already tried.
That last point saves everyone time. A ticket that says “500 error, here are the three log lines from 09:42 UTC, deactivating Plugin X did not clear it” gets a far faster answer than “my site is broken.”
When to ask hosting support
Not every problem is yours to fix, and pretending otherwise wastes hours. You can reasonably investigate plugin and theme conflicts, standard file permissions, cache behaviour, and broken references in your own site. Those live in your account and respond to careful, backed-up changes.
Send it to your host when the log points at the server or account layer. Database service failures, resource and process limits, ownership problems on system paths, web server configuration, and anything that persists after you have cleanly ruled out your own code all belong with support. These are areas where you often lack the access to fix things safely, and where a wrong move can affect more than one site.
If a site is badly broken, inherited from a previous developer, or you simply want someone to take the logs off your hands and sort it, that is a fair moment to bring in help. Our website rescue and hosting service exists for exactly that situation.
Final thoughts
Error logs remove the mystery from a broken website. Instead of guessing, you get a timestamp, a message, a file, and a line number, four facts that usually point straight at the cause. Learning to read one line well is a skill that pays back every time something goes wrong.
Keep the workflow simple: reproduce, match the timestamp, copy the lines, back up, change one thing, retest. Handle what sits inside your own site with care, and hand server-level and account-level problems to the people who manage the server. Used that way, your website error logs become the first tool you reach for, not the last, and most hosting problems get shorter and less stressful as a result.
