Tracking PHP Fatal Errors
The most impactful class of errors in a PHP application are Fatal errors, including uncaught exceptions.
Tideways helps you monitor these critical failures to ensure your application runs smoothly.
All errors include a message, stacktrace, and context information, like the classname in case of exceptions. For display, they are grouped together for an overview of your project.
PHP Fatal errors can be divided into two groups, errors that exist because of environment constraints like available memory, and errors that happen due to implementation.
Environment Constraints
When a PHP script is aborted due to factors like exceeding max_execution_time or
requesting more memory than memory_limit permits, Tideways will record a full
stack trace and mark the request as failed.
These failures are grouped together for an easy overview of how many times this happens across your application.
Code errors
Similarly, for uncaught exceptions and other fatal errors a full stacktrace is stored and errors are grouped by the call path leading up to the error. So they are handled like any other error recorded by Tideways.
| Many frameworks register "global" error and exception handlers. Tideways automatically instruments many of these and records these errors as well. Custom error handlers that hide or discard the exception are not visible by default but can use Profiler::logException($e) to send these errors to Tideways. |
Processes killed by the system
When a PHP process is killed by the operating system, Tideways can’t observe these errors.
This can happen when processes are stopped by the operating system.
For example, signals such as SIGKILL or SIGTERM, a PHP-FPM restart that hard-stops a request in progress,
or the system’s OOM-killer removing the PHP process.
This behavior is consistent with how PHP’s internal error logging works where these cases are also not logged.
To summarize the behavior: Everything that PHP could log into a file will also be seen and recorded by Tideways.