Error Tracking

Tideways automatically detects PHP fatal errors and exceptions and then de-duplicates (or aggregates) them. Error details include the message, stacktrace, and context information. These details help you fix your customer’s bugs as quickly as possible.

Error De-duplication

Error de-duplication aggregates, or avoids duplicating, errors which happen either at the same place or for the same reason. This functionality helps ensure that you have a more realistic, and less obscured assessment of errors occurring in your application. De-duplication is achieved based on a hash (or fingerprint) of:

The exception class name
All frames in the stacktrace of the exception/error, using only the class/function names, not the file name and the line where the error occurred.

What is a Fingerprint?

A fingerprint is essentially a hash of a place in the code where an error occurred. By default, a fingerprint uses the exception class' name and function names from an exception’s stacktrace. For example, if a stacktrace of an exception, FooException, is foo() ⇒ bar() ⇒ baz(), then the fingerprint is a hash over the exception class name and the functions foo`, bar, and baz. Some exceptions, however, have other ways to compute the fingerprint, for example, Max Memory Reached or Max Execution Time Reached, have static fingerprints. These fingerprints are always the same, regardless of where the error occurs. The code of an exception is not part of the fingerprint.

For deprecations the fingerprint is based on the message alone.

For warnings and notices the fingerprint is based on the file and line they were triggered on. The filename is cut to the last directory and filename.

Occurrences

When combined with the Deployment Events feature, then error occurrences since the last release to a production environment are reset to zero, re-triggering "New Exception" notifications, if the error still occurs.

Workflow Options

Figure 1. Error tracking workflow options

Tideways provides four error-tracking workflow options; these are:

Resolve: Resolve changes status from "Open" to "Closed". The error automatically re-opens if/when the error reoccurs.
Ignore: Ignore changes the error’s status to "Ignored", based on the stacktrace (fingerprint) leading to this error and does not show it again.
Always Ignore: Always Ignore changes the error’s status to "Ignored", based on the exception class' name, meaning everywhere this exception class is thrown.
Don’t notify: Don’t notify disables notifications via integrations for this error, based on the stacktrace (fingerprint).

Notification Triggers

There are three different triggers that can send notifications for errors/exceptions:

An error occurrs for the first time, then the "New" trigger is fired
An error occurrs again for the first time after a release was published, then the "Reappeared" trigger is fired
A closed error still occurrs, then the status is changed from "Closed" to "Open" and the "Reopened" trigger is fired

Resolve All Errors

In the error list the button "Resolve All" prompts for a confirmation to change the status of all "Open" errors/exceptions to "Closed".

If an error still occurs after marking all issues as resolved, then the "re-opened" trigger is fired and notifications are sent.

Still need help? Email [email protected]