Record what failed before changing the site
Write down the affected URL or admin action, its time and time zone, and the last known working result. Note any recent plugin, theme, WordPress or PHP change. Keep a restorable backup and access to your hosting control panel before troubleshooting.
For a public page, HTTP Status Checker can record the response NosHost receives. It cannot reproduce your signed-in admin action, cart session or background job. Keep those observations separate from the PHP error.
Recover access without exposing diagnostic details
If WordPress sent a Recovery Mode email, use its link privately. Recovery Mode may help with a fatal error during a normal page load; it does not cover every failure or background task. Do not paste its private link into a diagnostic tool or shared report.
Check the hosting provider's existing PHP error log first. If you need WordPress debugging, follow the official debugging instructions on staging. Keep WP_DEBUG_DISPLAY false and use a protected log location. Do not display errors to visitors or leave a downloadable log in the public website.
Collect the smallest useful log window
Keep the original log privately. Make a sanitized copy around the failed action, preserving error type, relative component path, line and timing. Remove credentials, cookies, personal data, private URLs and server account paths. Review the file yourself before selecting it.
- Open WordPress Fatal Error Investigator and select the PHP log import format in Input details.
- Enter the public source site URL without credentials or query strings, plus the actual collection time in UTC.
- Enter the real log-window start and end only when known. Mark the window complete only if logging was enabled throughout and the supplied file covers that whole interval.
Imports are limited to 2 MiB. The WordPress evidence guide explains supported formats and limits. The manual exporter does not collect raw error logs; a report with no error measurements cannot establish that PHP is healthy.
Read the groups as recorded failures
The report groups supplied errors by type, component path and line. A fatal or parse-error group gives you a location to inspect. A plugin may stop because another component passed invalid data, so the location is not proof of the original cause. Keep the original message and stack trace available for your developer; the derived export omits them.
An empty excerpt does not prove an error-free site. Missing window details, partial collection or stale evidence can leave checks unavailable. A complete window with no recorded fatal errors describes only that interval and the actions exercised during it.
Reproduce the action and verify the repair
On staging, repeat the same action with the same software versions and relevant test data. Apply a supported component update or reviewed code fix, changing one cause at a time. Avoid disabling all plugins on a live store to see what happens.
Repeat the failed action after the change, then collect a fresh log window and confirm the expected response or result. Keep the earlier evidence for comparison. NosHost reviews your manual snapshots; it does not change plugins, repair code or continuously watch the site.
Sources
Reviewed on 6 November 2026. WordPress debugging, WordPress Recovery Mode and WordPress guidance on displaying errors.