Use a private WordPress debug log to capture the actual error, keep error text out of public responses, and turn temporary diagnostics off when the investigation ends. A log can contain filesystem paths, request values, and sensitive plugin output. Hiding errors on screen does not make the log file private.
If the site already has a hosting error log with the required event, start there. For a crash that blocks wp-admin, follow the critical-error recovery guide and preserve access before making configuration changes.
Choose the log destination with the host
Ask for a writable path outside every public document root and static-file route. A path outside one WordPress directory could still be public through another host mapping. Verify access controls instead of relying on an obscure filename.
The WordPress debugging reference documents a file path for WP_DEBUG_LOG and separate display controls. A host-reviewed example is:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/private-host-path/site-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
The path is a placeholder, not a directory to copy unchanged. Edit existing definitions rather than defining the constants twice, and place them before WordPress finishes loading configuration. Back up the configuration through a private channel first.
Capture one reproducible failure
Record the local and UTC time, route, user role, component versions, and exact action. Reproduce with harmless test data where possible. Match the resulting event to that timestamp rather than treating every old warning in the file as the current cause.
Read the first relevant fatal error and its call sequence. A path in a stack trace can identify a caller or dependency, not necessarily the component that needs replacement. Ask a developer to interpret ambiguous traces before disabling unrelated plugins.
Evidence guide for this investigation. Record your own observations; the fields are not test results.
Share a redacted excerpt, not the whole log
Preserve error type, component path, line number, and the smallest sequence that explains the event. Remove authentication headers, cookies, tokens, email addresses, customer payloads, and signed URLs. Redaction should keep enough structure to distinguish two requests without exposing the original values.
Do not paste entire logs into public issue trackers or online formatters. A plugin can write more than PHP errors, including API request bodies. Review the excerpt even when the diagnostic configuration itself looks safe.
If a public log was already exposed, preserving incident evidence and restricting access come before routine cleanup. Determine what was present and who could access it. A deleted file may remain in a CDN cache or another retained copy; involve the responsible security and hosting teams.
Verify output and stop temporary collection
Check the affected page, API response, and background task after the repair. Confirm that diagnostic text does not leak into HTML or JSON. A setting that suppresses display is not proof every plugin respects the same output path.
Restore the intended production debug settings and follow the host's retention policy for the captured file and exported excerpts. Investigate repeated growth instead of allowing a new log to fill the disk.
For help interpreting the failure, send HandL WP a scoped diagnostic summary with sanitized evidence. Keep original private records available to authorized responders, but do not make unrestricted log collection a permanent substitute for targeted monitoring.
Sources checked September 30, 2026. Examples and visuals are explanatory, not customer measurements.