Turn a wall of log output into the one line that matters
Paste a PHP error log, WordPress debug.log, or web-server error log above. The analyzer groups repeated entries, separates fatal errors from noise, and surfaces the file and line behind each failure.
It runs entirely in your browser — the log is never uploaded, which matters because logs routinely contain file paths, and sometimes far more.
Before you paste anything
Logs leak. A stack trace can contain database credentials passed as function arguments, API keys, session tokens, customer email addresses, and your full server directory structure.
Processing here is local, so nothing leaves your machine. But build the habit anyway: scan for secrets before pasting a log into any tool, support ticket, or forum post. Public forum threads containing live credentials are depressingly common.
Read the first fatal, not the last error
This is the single most useful habit in debugging WordPress. A single failure cascades: one fatal error produces dozens of follow-on warnings and notices as the rest of the request falls apart. People read the bottom of the log, find a warning in an unrelated file, and spend an hour on a symptom.
Work from the timestamp of the first fatal error. Everything after it in that request is usually consequence, not cause.
What the common entries actually mean
| Entry | Meaning | Where to look |
|---|---|---|
| Allowed memory size exhausted | PHP hit its memory ceiling | The named file shows where it ran out, not what wasted it. Look for a plugin loading everything at once. |
| Maximum execution time exceeded | A request ran too long | Usually an external API with no timeout, or an unindexed database query. |
| Call to undefined function | Code ran before its dependency loaded | A plugin calling something too early, or a missing PHP extension. |
| Cannot modify header information | Output was sent before headers | Whitespace after ?> in a theme or plugin file. The named file is the culprit. |
| Deprecated / Notice | Old code on a newer PHP version | Rarely the cause of an outage. Note it, then keep looking. |
| White screen, empty log | Errors are being suppressed | Enable WP_DEBUG_LOG with display off, reproduce, then re-read. |
Finding the log in the first place
- WordPress debug log —
wp-content/debug.log, but only onceWP_DEBUG_LOGis enabled. If the file does not exist, logging was never switched on. - Host error log — in cPanel or your hosting dashboard, often "Errors" or "Error Log". This catches failures that happen before WordPress loads, which the debug log cannot.
- PHP-FPM / server log — needed for 500s and timeouts, where PHP died before WordPress could record anything.
If debug.log sits at its default path it is usually downloadable by anyone who guesses the URL. Block it at the server, or move it above the web root.
Related tools
- wp-config.php Generator
Switch on debug logging without printing errors to visitors.
- .htaccess Generator
Block public access to debug.log once logging is enabled.
Frequently asked questions
Is my log uploaded when I paste it here?
No. This analyzer runs in your browser and the log never leaves your machine. You can verify that by opening the network tab while you paste, or by disconnecting from the internet and using the page offline. Even so, check any log for credentials before pasting it into a support ticket or forum, because those are not local.
Where is the WordPress debug log?
At wp-content/debug.log, but only after WP_DEBUG_LOG has been enabled in wp-config.php. If the file is missing, logging was never turned on rather than there being no errors. For failures that happen before WordPress loads - 500 errors, PHP crashes - you need the host's error log instead.
My site shows a white screen but the log is empty. Why?
Error display and logging are both switched off, so the fatal error is discarded. Set WP_DEBUG and WP_DEBUG_LOG to true with WP_DEBUG_DISPLAY false, reload the broken page to reproduce the failure, then read the log. If it is still empty, PHP is failing before WordPress runs - check the host error log at that timestamp.
Which error should I fix first?
The first fatal error by timestamp. One failure cascades into many follow-on warnings as the rest of the request unravels, so the entries at the bottom of the log are usually consequences rather than the cause. Deprecation notices and warnings are worth recording but rarely explain an outage.
The log names a file in wp-includes. Is WordPress core broken?
Almost never. Core files are where execution stopped, not where the mistake was made. A plugin usually passes bad data into a core function, and core is simply the place it fails. Read the stack trace and find the first entry outside wp-includes and wp-admin - that is normally the real source.
Maintained and reviewed
Last reviewed 2026-07-21. Covers PHP error logs, WordPress debug.log output, and web-server error logs.