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 Grouping

Errors are grouped together when they happen at the same source code location, or are raised in the code for the same reason.

This functionality helps ensure that you have a more realistic, and less obscured assessment of errors occurring in your application.

Grouping is achieved based on a fingerprint. All errors with the same fingerprint are grouped together.

For exceptions and fatal errors the fingerprint

The exception class name
All class and function names in all frames in the stacktrace of the error.

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, have other ways to compute the fingerprint, for example, Max Memory Reached or Max Execution Time Reached, have static fingerprints and all occurrences are grouped together. These fingerprints are always the same, regardless of where the error occurs. The code of an exception is not part of the fingerprint. Connection and Timeout related exceptions of several libraries are also grouped together.

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

You can navigate through all occurrences of the same grouped error and evaluate differences in context variables and stacktrace.

By default the latest occurrence of an error is selected.

For each error the number of occurrences over all time and since the last release is counted, as well as the first and last time they were seen.

When combined with releases, the occurrences since the last release are reset to zero. When the error is seen again, it triggers the "New Exception" notifications once more.

Stacktraces

Each error is rendered with a stacktrace that shows the file and line were it was triggered including all frames that lead up to the error.

Stacktrace of an error with different actions

There are several actions available from the stacktrace:

Code context allows to see the code for each stackframe. When enabled the code for the first frame is shown by default, and a click on the file:line in each frame opens or collapses the code.
When you configured an IDE integration for this project, the file and line can be opened directly in the IDE by clicking its icon.
When a stackframe is from a Composer vendor/ directory and Composer instrumentation is enabled in the PHP extension, a link to the GitHub or Gitlab source code viewer is shown.
When the stackframe has a symbol with a name (non-closure, non-anonymous class) then you can copy it to the clipboard.
The whole stacktrace can be copied to the clipboard as text, as a preparation to paste it into an issue tracker ticket, chat or email.

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.