Disable error output in production without losing diagnostic capabilities.
In production, `display_errors` is disabled, while errors are securely logged and actively monitored with time, context, and correlation identifiers.
"Reliably diagnosing PHP errors" is discussed here from the perspective of "PHP Runtime, HTTP, and Diagnostics." For PHP developers and website operators, "Neutral Publicity" and "Accidental Detailed Output" are particularly important.
Published: 3 min read · Author: Sebastian Geier
How can PHP errors remain investigable if details are not allowed to appear in the browser?
`display_errors` is disabled in production, `error_reporting` captures the intended levels, and `log_errors` writes outside the web root. A central handler assigns a non-sensitive ID, logs secure context, and provides a robust error response; access, rotation, and alerts are handled separately.
Test case: "Accidental detailed output"
A database exception previously appeared as a blank screen because all error handling was disabled. The application now returns a 500 with a short ID, while the protected entry contains the release and secure stack information; an alert reports the first incident of the new class.
Neutral Public Access
Test criterion
Neutral Public Access
Browsers, APIs, and proxies receive the appropriate status and event ID, but no paths, queries, tokens, or stack details.
Test criterion
Protected Diagnostic Context
Time, route, release, exception, and necessary metadata are internally traceable and accessible only to authorized personnel.
Monitored Log Path Write errors, memory limits, rotation, and alerting are checked to prevent diagnostic failures from going unnoticed.
Accidental Detailed Output
Accidental Detailed Output An environment variable activates `display_errors` after deployment, revealing internal information directly in production responses.
Sensitive Log Data – Request body, session, password, or form content are logged indiscriminately, creating a new data leak.
Silent Log Failure – Incorrect permissions or a full disk stop logging, while users only see neutral, unrelated errors.
Monitored Log Path
Control signal
Signal 1
Proportion of productive exceptions with a correct status and a retrievable event ID, without sensitive details in the response.
Control signal
Signal 2
Log write errors, discarded events, and time from a critical exception to the appropriate alert.
Protected Diagnostic Context
Explicitly and testably define the production configuration for display, capture levels, and protected log destination.
Implement a central exception path with a secure event ID, data minimization, correct status, and robust view.
Trigger controlled exceptions and regularly check the response, log correlation, access, rotation, and log failure alerts.
How "Safely Diagnosing PHP Errors" relates to other topics
A relevant follow-up question answered Securely Reading JSON Files and Responding to Erroneous Data"How does PHP unambiguously respond to a missing, unreadable, or invalid JSON file?"
A second connection for "Safely Diagnosing PHP Errors" leads to Completely Check Internal Linking After a RelaunchThis post remains focused on the question, "Which checks reliably uncover lost internal pathways after a relaunch?"
If you want to put "Safely Diagnosing PHP Errors" into practice, you can refer to Robust Website Systems This focuses on "PHP Runtime, HTTP, and Diagnostics" and "Neutral Publicity."
Conclusion: Safely Diagnosing PHP Errors
Secure error handling separates public information from internal diagnostics. Neutral responses are only operational if correlation, log protection, and log availability have been thoroughly tested.
Sources and Further Information
The following sources document the technical and methodological guidelines used for "Reliably Diagnosing PHP Errors."
Runtime Configuration for Error Handling – PHP ManualThe official PHP documentation defines `error_reporting`, `display_errors`, `log_errors`, and other runtime rules.
PHP-FPM Configuration – PHP ManualThe PHP manual describes the process manager, worker limits, status path, timeouts, and logging for PHP-FPM.
RFC 9110: HTTP SemanticsThe Internet standard defines the semantics of methods, status codes, fields, and error responses.
Key Thesis
`display_errors` is disabled in production, `error_reporting` captures relevant stages, and `log_errors` writes to a protected destination. Users see a neutral identifier that allows them to locate the incident in the central log.
What This Is Not About
Production errors must neither appear in the browser with stack traces nor be made invisible by completely disabling error capture and logging.
What it's about
Public responses remain neutral, while relevant error stages are logged in a protected central destination with a correlable event identifier.
PHP, forms & security
Building a Security and Error Log for Production Forms
"Reliably Diagnosing PHP Errors" includes, as a separate test step, the question: Which form events should be logged without creating new data privacy or security risks?
PHP, forms & security
Building PHP forms so that errors remain traceable rather than invisible
Supplements "Reliably Diagnosing PHP Errors" with a separate decision: How can a PHP form display errors clearly while simultaneously providing enough data for diagnosis?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Neutral public: next reliable decision
In a near-production environment, a controlled exception should be thrown. No technical details should appear in the browser, while the internal entry remains immediately accessible via the displayed ID.