Quick answer
Capture the failing URL, approximate time, and matching error-log entry before changing configuration. An error log helps locate the failure, but it can contain private paths or request data. Share a sanitized excerpt rather than a complete unreviewed log.
Before you start
Reproduce the problem safely and note whether it affects one page, all pages, login, an upload, or a scheduled job. Use the correct hosting account and time zone.
What to do
- Open the available Errors view or the application's supported log and match entries to the recorded request time.
- Identify the first relevant error rather than treating every later warning as the root cause. Compare recent code, plugin, PHP, and configuration changes.
- Redact credentials, tokens, customer details, and unrelated paths before sending the excerpt to support or an AI assistant.
- Make one narrow, recoverable correction in staging where possible, then retry the same request and inspect the resulting log.
Check the result
Confirm both the visible behavior and the absence of the original failure. A blank page or suppressed error display does not mean the underlying problem is fixed.
If something does not work
If no matching log is available, ask support with the exact URL and time. Avoid enabling verbose public debug output on production, where it can disclose sensitive information.
Related help
- Log PHP errors privately instead of displaying them to visitors
- Connect Your Domain: DNS, Nameservers & Cloudflare
- Report and investigate a WordPress critical error
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
