Setting the file. One moment.
Chapter 158 · Omnibus Instrument Error Tracking
Subchapter 158.9
references/monitoring.mdMarkdown9 KBView on GitHub
This guide covers how to find the most relevant, urgent, and impactful issues in your error tracking using the issues page.
When you’re monitoring issues in your project, there are generally two common workflows:
Assigned to property.Issues can be sorted by the following properties:
| Property | Description |
|---|---|
| Last seen | The issue that has the most recent exception |
| First seen | The issue that has the oldest exception |
| Occurrences | The number of exceptions in the issue |
| Users | The number of unique users affected by the issue |
| Sessions | The number of unique sessions affected by the issue |
Sorting by last seen and occurrences are great ways to get a general sense of issues in your project. Sorting by users and sessions is great to find the most impactful issues if you’re using other filters to narrow down your results.
You can filter issues by the Assigned to property to find issues assigned to you. This is especially useful if you configure automatic issue assignment (opens in a new tab) and configure alerts (opens in a new tab) to notify you when new issues are created.
You can use the search bar at the top of the issue page (opens in a new tab) to filter issues based on the properties of the exceptions in that issue.
Search results are matched based on properties of exception events (opens in a new tab) grouped into the issues. For example, if you search for “TypeError”, we show you all issues where any exception grouped into the issue has a type of “TypeError”.
Unrelated results
You may see seemingly unrelated issues in your search results because your search term matches an exception in the issue group. For example, you may see an issues named RefreshError when searching “schema”, because a get_schema method appears on the exception stack traces.
The search bar provides two modes of filtering:
This operates like property filters elsewhere in PostHog, enabling you to add terms like where 'http_referer' is set or where 'library' equals 'web'. You add a property filter by clicking the property name shown here:
Added property filters look like this:
The results of both of these filter types (property filters and freeform search) are combined with AND logic, such that only exceptions that match all filters are included in the search results.
This does text matching for a subset of the error tracking specific properties of the exception event. It splits the text you give it into tokens. The search matches an exception if each of the tokens in your search term appear in one of the following:
For example, imagine you have an exception that looks like this:
PostHog AI
TypeError: Cannot read property 'name' of undefined
at Object.<anonymous> (/path/to/myfile.js:123:45)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3)
at Function.Module.runMain (module.js:694:10)
at startup (bootstrap_node.js:204:16)
at bootstrap_node.js:625:3If you search for the term TypeError myfile.js, the exception matches this search, as it contains TypeError (as the exception type) and myfile.js (as a file path in the stack trace).
If you search for TypeError myfile.js abc, the exception would not match, as the token abc does not appear anywhere in freeform search properties.
If you want to search for longer exact strings, e.g. a particular exception message, you can group tokens into a single term using quotes, e.g. "Cannot read property 'name' of undefined" myfile.js would match, and "Cannot read property of myfile.js" would not.
Note, perhaps unintuitively, Cannot read property of myfile.js would match, because the tokens are ungrouped, and all of them appear somewhere in the exception search properties.
Exception events can have more than one exception in them, due to language features like exception chaining. For freeform search, we put the types, messages, functions and file paths of all exceptions into one list, and match if the token appears in any of them.
For example, if you had a chained exception with the messages MyCustomError: Failed to load user and Cannot read property 'age' of undefined, searching for cannot read property would match the exception, because it matches one of the exception messages (property appears in the “root” one).
When you click on an issue, you’ll see the details page of the issue.
This page shows you the following:
Once you’ve found and opened the issue you want to investigate, you can use the same search interface to filter the exception list for a particular instance of the issue. This is particularly useful in cases where some exceptions in the issue have information others don’t and you want to use that information for debugging.
For example, you can add a property filter on http_referer that shows all exceptions where the http_referer is set:
Alerts
If you have a set of filters that you use often, you can create alerts for them. This way you can be notified when new issues match your filters. Learn more about alerts (opens in a new tab).
We try to return results to you within a second, but sometimes if you’re querying over large amounts of data, it may take longer. The following can improve the search performance:
Limit the time range you’re searching over: 7 days is usually enough to get a sense for the trends of an issue over time.
Use freeform search rather than property filters: Our freeform searches are generally faster than property filters, as the total amount of data processed is smaller.
If you find your queries timing out or taking more than 30 seconds, please let us know in-app (opens in a new tab)! We’re always looking for benchmarks to improve against.
If you find issues that are not useful to you, you can suppress them by changing the status to Suppressed. We recommend that you also implement client-side suppression (opens in a new tab) to not capture these exceptions in the first place, for cost and performance reasons.
Ask a question
HelpfulCould be better