Errors and issues
How Apperio groups errors into issues, counts sessions, and spots regressions.
What counts as an error
Any log at level error or fatal becomes part of an issue. In the browser that includes, with the default settings:
- uncaught errors and unhandled promise rejections;
- requests that fail outright, and responses with a 5xx status;
- whatever you send with
logger.error(),logger.fatal()orlogger.captureException().
With consoleMessages turned on, every console.error() call counts too. See Auto-instrumentation.
How errors are grouped
Each error gets a fingerprint built from three things:
- the error’s name, such as
TypeError; - its message, with the parts that change between occurrences replaced: IDs, long hex strings, numbers of two or more digits, timestamps, and URL paths and query strings;
- the top five frames of the stack trace, without line and column numbers, query strings or domains.
Errors with the same fingerprint form one issue, titled with the name and message, for example TypeError: Cannot read properties of undefined. Grouping is deliberately cautious: two different bugs wrongly merged hide one of them, so when in doubt Apperio keeps them apart.
Errors without a stack trace
Server Error entries for 5xx responses, are grouped by name and message alone. All 5xx responses therefore land in one issue; open it and use View events in logs to see which requests failed.The Issues page
The list shows each issue’s Events, Sessions, Last seen and Status, with the environments it appeared in and the release it was first seen in. Click an issue to open it:
| Part | What it shows |
|---|---|
| Occurrences, Sessions affected, Last seen | How big the problem is and whether it is still happening. |
| Likely caused by | Recent commits that probably introduced it. See Suspect commits. |
| Stack trace | The stack from the most recent occurrence. |
| Watch replay | Appears when a recorded session hit this error (session replay, beta). |
| View events in logs | Opens the Logs page filtered to this error’s message. |
| Resolve, Ignore, Reopen | Change the issue’s status (owner or admin). |
| Create GitHub issue | Drafts a GitHub issue from the error. See GitHub issues. |
Related pages: Suspect commits, GitHub issues, Session replay.
Sessions affected
A session is one page load in one browser tab (see Sessions). Sessions affected counts the different sessions an error appeared in, so one visitor who reloads three times and hits the error each time counts as three. The count stops at 500.
Statuses and regressions
- Unresolved: new issues start here.
- Resolved: you marked it fixed, or closed its GitHub issue (shown as Resolved via GitHub).
- Ignored: it keeps counting new events but stays out of the Unresolved list and doesn’t notify you again.
- Regressed: a resolved issue that happened again. It goes back to Unresolved with this label, and the owner is notified, at most once every 30 minutes for the same issue.
Notifications
The first time a new kind of error appears, the project owner is notified in the app and by email, with no alert rule needed. Repeat occurrences of a known issue don’t notify. See Notifications and alerts for the environment filter and for alert rules.