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 Tracking in Tideways

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.


When combined with the Release Tracking 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

Error tracking workflow options in Tideways
Figure 1. Error tracking workflow options

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


Resolve changes status from "Open" to "Closed". The error automatically re-opens if/when the error reoccurs.


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).

Managing Ignored Exceptions

When an exception class is marked as "Always Ignore" then all occurrences of this exception anywhere in the project are immediately marked as "Ignored".

The "Ignored Exceptions" sub-screen in the Error Tracking project settings shows which exception classes are classified to be always ignored and allows to remove an exception from this list again.

In addition this screen lists a number of exceptions as always ignored by default, mostly from well-known frameworks and libraries that are using these exceptions for control-flow and not to signal actual errors.

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".

resolve all

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

Further reading

Still need help? Email [email protected]