WordPress debug.log empty? Prove it sees the failure
An export fails at the same point each time. The visitor gets an error. Yet debug.log has the same timestamp it had yesterday.
That contradiction is irritating, especially when a service business in Dubai, the UAE, Liverpool or the UK needs the site working before a report, booking list or customer record is due out. It is also easy to misread. An unchanged WordPress debug.log does not prove PHP has nothing to say. It only tells you that this file did not record that request.
Start with the time of the failed request
Before opening settings or retrying the export ten times, write down the exact failure time, including timezone if the hosting dashboard uses one. A useful note is simple: export started at 14:07, error shown at 14:08, logged-in administrator account, same result on a second attempt.
Repeated reloads are rarely useful after that. They can create a pile of near-identical requests and make the useful moment harder to match against server records. This is a website repair job where one clean reproduction beats a bit of hopeful clicking.
A blank WordPress debug.log can result from disabled debugging, a custom log destination, a path WordPress cannot write to, an error occurring before WordPress loads, or a fault handled by PHP, the web server, a proxy or hosting security tooling. Check the active logging setup and compare one timed reproduction with the hosting error log before deciding which layer owns the failure.
Check the configuration WordPress is actually using
WordPress documents that WP_DEBUG_LOG depends on WP_DEBUG being enabled, and that the log can be sent to a custom file path rather than the usual location. WP_DEBUG_DISPLAY is a separate setting. Turning off public error display does not switch off logging, which is exactly how it should be on a live business website. The WordPress debugging documentation explains those prerequisites.
Check the active values rather than relying on a remembered change from last year. A developer may have set a custom destination during an earlier repair. A staging copy may have different settings. Occasionally the file being watched is simply not the file the live site is configured to use.
- Confirm that WP_DEBUG is enabled for the test.
- Confirm that WP_DEBUG_LOG is enabled and note its configured destination.
- Keep WP_DEBUG_DISPLAY disabled on the public site.
- Check whether the expected log file exists and whether its modification time changes during a controlled test.
- Confirm that the relevant directory is writable by the process running PHP, without reaching for broad permission changes.
The last point is deliberately dull. File ownership, PHP process users and hosting restrictions vary. Changing permissions at random may create a new security or maintenance problem without answering why the request was not logged.
Follow the request beyond WordPress
WordPress logging begins only after WordPress and PHP have reached the relevant point. A request can fail earlier. PHP-FPM, Apache, Nginx, LiteSpeed, ModSecurity, Cloudflare, a host-level resource limit or a timeout can all leave evidence elsewhere, depending on the hosting setup.
Look in the hosting control panel for the PHP error log and web server error log first. On managed hosting, the provider may expose these through a dashboard or supply them on request. Match entries to the time you wrote down, not merely to the same date. Server clocks and WordPress timestamps are not always aligned, which catches people out more often than it should.
If a visible failure follows a PHP version change and the server log records a fatal error, use the more specific route for a WordPress 500 error after a PHP update. That is a different diagnosis from an empty debug.log: the priority there is reading the server-side failure record and checking compatibility, rather than assuming WordPress logging is comprehensive.
An export failure with no new debug entry
Take a typical service website export. An administrator selects a date range, starts the export and receives a generic error after a short wait. They refresh debug.log, but it has not changed. The tempting conclusion is that the export plugin has no PHP problem.
Perhaps. But the export could instead be exceeding a hosting process limit, timing out in PHP-FPM, being blocked by a security rule, or failing before the WordPress error handler has any chance to write its line. The unchanged file has not cleared the plugin. It has not cleared the server either. It has supplied one narrow piece of evidence.
For broader WordPress incidents, a structured critical error repair checklist can help keep the work ordered when the screen message itself is vague. The important distinction is scope: an empty log is a logging-coverage question first, not a verdict on the fault.
Run one controlled retest after the checks
Once the configuration, destination and write path have been checked, reproduce the same action once. Keep the conditions close to the original failure: same account type, same export range, same browser route where practical. Record the time again.
Then compare three things: whether the WordPress log changed, whether the hosting error log has an entry at the matching time, and what the browser received. A 500 response, a timeout, a 403 response and a successful response with a broken download are different trails. Treating them as one generic error is how a quick repair turns into an afternoon.
What counts as enough evidence to escalate
You do not need a giant archive of logs. You need a short, usable incident record: the affected URL or admin action, exact failure time, timezone, response or visible message, active debug settings, expected log path, whether its timestamp changed, and a sanitised extract from the hosting log around that time. Remove customer data, passwords, tokens and private paths where necessary.
That evidence makes it much easier to decide whether the next move belongs in WordPress, the plugin or theme, the PHP runtime, or the host. It also gives a repairer something better than a screenshot of a blank file. For wider faults affecting an important lead generation website, see the scope of website repair support for businesses in Dubai.