When WP_DEBUG_LOG is enabled with the default value, the file is usually built in wp-content/debug.log. The absence of a file does not mean the absence of an error: the content path can be custom, PHP does not have write permission, or the error occurs before WordPress bootstrap. The goal is not just to find the file; You should attach a specific message to the same broken request.
Quick answer: Reproduce the error once with the exact time, know the timezone of the log, read the lines around the same time and follow the first Fatal or Exception associated with the project code. The last line of the stack trace or an old warning is not necessarily the root cause.
How is the file path determined?
With the value true the usual destination is inside the content folder. If WP_CONTENT_DIR has changed or another path is specified for WP_DEBUG_LOG, the file will be located elsewhere. The destination must be writable by the PHP user and protected from public download. The wp-config file contains secret; Don't post it for help.
If debug.log doesn't build
- Make sure the constants are defined before the wp-config stop line and only once.
- Rerun the broken request and record the timestamp.
- Match the ownership and permission of the path to the PHP user; Do not use
777. - See PHP-FPM, Apache or Host Panel log.
- In Docker, check volume, stdout and node executing the request.
Fatal related to syntax in wp-config or missing extension may occur before WordPress logger and only PHP level can be seen in the error log.
Start from the time, not the plugin name
Note the click or job hour in seconds and specify the timezone difference of the operating system, PHP and WordPress. Then separate a small gap. Searching for the plugin name may return hundreds of irrelevant warnings from the previous days. In some backends, the request ID is the best way to connect the proxy, PHP, and application logs.
tail -n 200 wp-content/debug.log
grep -nE "PHP Fatal|Uncaught" wp-content/debug.logThese commands only read the file, but the output may contain sensitive data. Match the path with the actual installation and don't paste the whole file in the public space.
Interpret Severity correctly
| type | meaning | Action |
|---|---|---|
| Fatal / Uncaught | Usually stopped request | Follow the message and the first related frame |
| Warning | Continuable execution or invalid data | Measure time and effect correlation |
| Deprecated | Old API | fix for future compatibility; The cause is not necessarily certain |
| Database error | query, connection or schema | Compare the MySQL log and operation of the same request |
How to read the stack trace?
Start from the exception message and the file, then follow the frames to the first code belonging to the plugin, template or project. The last frame is usually the general dispatcher. If two components are in trace, reproduce the composition of versions in staging; The name of the last file is not a sufficient reason to remove the plugin.
Why does the file suddenly get bigger?
Warning inside the loop, bot traffic or leaving debug on can cause high I/O and full disk. Maintain the required sample, modify the repetition source and define rotation and retention. Deleting a file without fixing the cause only takes a few minutes.
What should be deleted before sharing?
- cookie, nonce, token and authentication header
- password and database DSN
- email, phone, IP and order data
- API key and full webhook payload
- Paths including system username
From discovery to provable fix
Write a hypothesis from the message and trace, just change one variable in staging and run the original scenario again. Absence of Fatal freshness and healthyness of adjacent paths should be controlled. To enable secure logging, see the WordPress Debug Guide.
Adapt WordPress logs to server logs
A 500 response may record program message in debug.log, termination cause in PHP-FPM and only upstream failure in Nginx. Neither alone is the complete picture. Put status, request duration, PID or request ID and timestamp together. If the OOM Killer system closed the process or a timeout occurred outside of PHP, the debug.log probably won't show the last cause.
What should we test after the fix?
Rerun the original URL, login path, REST API, cron, and the operation the broken plugin was doing. The absence of a previous message is not enough; The answer should be correct in terms of data and side effect. Collect a few minutes of fresh log monitor and temporary workarounds, additional debug and opened accesses.
When is expert review necessary?
If the error is intermittent, multi-server or load-dependent, multi-layer data should be correlated. WordPress technical troubleshooting service Can be used for coordinated analysis of WordPress, PHP and web server.
Frequently asked questions
Can debug.log be cleared?
After holding It is possible to have the necessary sample and source fix, controlled rotation or truncate; First, consider the disk space and backup.
Why is the log time different?
The timezone of the layers is different. Measure the difference and convert all timestamps to a base.
Does every Deprecated require a rollback?
No; It must have a correction plan, but its relationship with the current failure must be proven.