The Issues page enables users to review all their frontend issues in one place and prioritize and learn more about the issues that are actually affecting the customer experience. The histogram at the top, visible when clicking the "See histogram" button, provides a quick snapshot of the health of your application by summarizing the number of sessions that are experiencing severe issues, any non-severe issues, and no issues.
- Network Errors - Failed network requests. These errors may or may not directly impact the UI.
- Rage Clicks - Occurs when a user clicks repeatedly in frustration on an element.
- Dead Clicks - Occurs when a user clicks on an interactive element (button, link, etc), but the click had no visible effect (ie. a DOM change).
- Frustrating Network Requests - Compound events where a user shows impatient mouse actions during a particularly long network request.
- Error States - Triggered by the occurrence of Element Visible Definitions that are designated as "error states".
Issues are retained for 1 month from the last instance of an issue. So if an issue stops occurring, it is available for 1 month after the last time it occurs. Issues retention is independent of an organization's session retention.
The status tabs separate the lists of issues based on prioritization, starting with "Needs Triage", or the issues that have yet to be given a status. High Impact, Low Impact, and Ignored issue lists can also be viewed by tabbing through this navigation.
Below the status tabs, you'll see a list of Issues from across your application, along with some metadata about each issue.
To the right of the issue title and message, you'll see the prioritization level of the issue, as well as a frequency histogram of its occurrences. At the end of the row, you'll see some additional metadata, including the number of users and sessions the specific issue has affected.
New issues will be automatically listed in the Untriaged section of the page. From here, you can choose to group issues based on their severity and impact to the user.
In order to categorize an issue directly from here, click the dropdown labeled Untriaged in the issue row and select whether the issue is High impact, Low impact, or should be Ignored completely.
You can also choose to open the Configure Issue modal. This allows you to add custom rules to group issues together and assign them the same status. You can choose to group based on the contents of the error message or the type of error. You can also assign the group a custom name.
Any new issues that arise within your application and match any of these rules will be auto-categorized into the selected status.
You can also categorize and group issues directly from their Issue Detail page.
Grouping issues must be of the same type
The Error State issue type groups instances where users receive a message indicating that something went wrong. This can include error pages, modals, or views. Error States are defined by the user for the each project in Definitions.
To enable Error State issues, on the Issues view click the Issue Types filter and click "Setup" next to the "Error States" option.
A Definitions side modal will open. Click "Add Definition" and create new "Element visible" definitions with the "Use as Error State" checkbox checked.
As you create these definitions, error state issues will begin to be recorded in LogRocket. Note: Element visible definitions are non-retroactive, meaning they will record events after being defined, but will not look back in time before their creation date. This means that once Error State definitions have been created, new Error State issues will start appearing from that point on, so you may need to check back in a few hours after creation to see the error states that users have hit.
Quickstart: Start out with default error state definitions
The quickest way to get started with Error State issues is to let LogRocket create them for you!
Check out the Default Error State Definitions doc to see how to bootstrap default error state definitions.
In order to see issues that only occurred in specific areas of your app, use the Definitions filter. Once Definitions are selected, issues listed will be ones that have occurred within those Definitions (on those specific URLs) in your app.
Definitions (using the "Visited URL" filter) are a shared feature of LogRocket and can be found in the main navigation. To add Definitions, either click the gear at the top of the "Select a definition" dropdown or go to the "Definitions" page and add new page Definitions.
By default, issues listed have occurred any time within the selected time range. You can use the First Seen filter to identify issues that have occurred for the first time within the selected time range, but may have continued occurring afterwards. Note that the 1 month issues retention also applies to the First Seen filter, so the first occurrence of an issue is based on events within the past month.
You can click through on an individual issue to view more detailed information about the issue, including a sample playback of a user encountering the issue within a session. This is designed to give you information to help you categorize the severity and priority of the issue. For example, issues that block users within a critical sign-up or checkout flow may be deemed higher-priority than issues that occur silently with no real user impact.
The list to the left of the session playback shows the metadata associated with the specific session playback. The grey bars on the right-hand side represent cumulative information about the issue, such as frequency of occurrence, most common browser, and number of users and sessions impacted.
Below the playback is additional information related to the error. This includes stack traces if you have provided us with sourcemaps, and request and response information if the issue type is a network error.
Updated 4 months ago