What you will learn #
Use Experience errors to find issues observed in recorded visits, inspect affected visits and investigate available replay context. A report cannot show errors from visits that were not admitted for recording.
Before you begin #
Availability: This feature is being opened gradually. An eligible plan or trial does not by itself enable it for every website. The following instructions apply when your website has access; follow its displayed access message.
- Add the Hitsteps tracking code to the pages you want to monitor. Use the installation instructions in How to track website visitors.
- Experience access is gated. The current access screen says Experience is included with active Pro plans and above; eligible accounts may be offered a 14-day Experience trial. Availability can also depend on the account and site. If you cannot open Experience, check the access message and your plan or ask the account owner. Do not assume the feature is enabled just because another site has it.
- Recording visitor sessions must be on for new visits to be captured. The recording switch is off by default on a newly configured site. Error tracking is a separate setting and is on by default in the source defaults. A site using heatmap-only capture does not collect errors.
- The visitor's consent and browser privacy choices, the site's capture rules, and the current Experience access grant still apply. An excluded page or visit will not provide error evidence.
- Allow time for a new recorded visit and its report data to appear. The report covers retained data, not every request made by every visitor.
Step by step #
A practical error review
- In Experience → Settings → Errors & diagnostics, check Error tracking. For more detail, review Detailed JavaScript errors, Network diagnostics, and Not-found page detection. These controls affect capture; changing them does not recreate events from earlier visits.
- Confirm Record visitor sessions is enabled in the same settings page. Keep the site's consent, Do Not Track, allowed-origin and included/excluded-page rules in mind.
- Return to Experience → Error tracking and select a useful date range. The report defaults to the latest 14 UTC calendar days when no range is supplied.
- Choose the report that matches the question: grouped messages, individual occurrences, affected pages, impacted sessions, or affected browsers.
- Narrow the results by type, page, browser, device, operating system, country, environment, or issue status when those choices are available. On Recent errors, a minimum occurrence count can help reduce one-off noise.
- Open a row and compare its message, type, state, time, page, source location, environment, and browser context. A source location is a clue, not a guarantee that the same line is responsible in every release.
- If Replay this moment is available, use it to see the recorded visit around the occurrence. The recording may still be processing, unavailable, expired, or excluded.
- After deploying a fix, mark the issue resolved if that action is available. Review later occurrences to see whether the same issue appears again. Resolving an issue changes its workflow status; it does not repair the website or erase prior evidence.
Worked example
Imagine your-store.example has a fictional grouped issue: TypeError: Cannot read properties of undefined. Its row shows 12 occurrences across 8 affected visits on /checkout/, with a JavaScript source location and Chrome as the browser family. These are illustrative values, not Hitsteps data.
Open the issue, inspect a recent occurrence, and use Replay this moment if the visit is playable. Check what happened immediately before the error, then compare another affected visit. If the source location is present, share it with the developer alongside the browser and page context. After the developer deploys a fix, mark the issue resolved and watch for new occurrences. A reduction in the report is evidence to investigate further, not proof by itself that every visitor is fixed.
Filters and issue actions
Filters available in the report query include date, type, page, browser, device, operating system, country, environment, status, and page matching. Depending on the view, you can also narrow by message, exact browser version, visitor/session, or issue. The recent-occurrence view accepts a minimum occurrence count. Use the filters offered by the current report; available filters can differ between views.
The issue detail can show individual captured events, page and browser context, a stack trace or diagnostic summary, an affected-session panel, and replay links. When workflow controls are available, you can bookmark an occurrence, change issue state, create or revoke a temporary share link for one occurrence, or delete an occurrence and its repeats. Sharing exposes that occurrence's message, source, and trace to anyone holding the link until it expires; the recording and visitor details remain private. Deletion is permanent for the occurrence and repeats, and revokes related share links. Use these controls only when you intend those effects.
Worked example #
Illustrative example: An issue called TypeError: Cannot read properties of undefined has 12 occurrences across 8 affected visits on /checkout/. Filter the issue, inspect its source location and browser context, and open a retained recording when available. These fictional counts distinguish occurrences from visits; they do not prove the issue caused a failed payment.
Controls and metrics #
| View or term | What it tells you |
|---|---|
| Open issues | Count of issues in the open state within the report's retained-data scope. |
| Affected visits | Number of recorded visits associated with error occurrences. It is not a count of all site visitors. |
| Occurrences | Captured error events in scope. Repeated events can contribute more than once. |
| Resolved | Count of issues marked resolved within the report's retained-data scope. |
| Recent errors | Individual occurrences, with visit and replay context when available. The minimum-occurrence filter is supported here. |
| Grouped errors | Matching messages grouped so recurring issues can be reviewed together. A group is not necessarily one root cause. |
| Pages | Pages on which matching errors occurred; open a row to inspect its occurrences. |
| Impacted sessions | Recorded visits affected by the errors; replay is available only when the relevant recording is playable. |
| Browsers | Browser families and versions associated with occurrences. Use this to compare patterns, not to infer every user's setup. |
| Error / JavaScript error | A captured browser JavaScript exception. Detailed JavaScript error capture is an optional setting. |
| Network | A captured failed request or network diagnostic. Network diagnostics can include request metadata and timing; they do not capture page content according to the settings description. |
| Not found | A page detected using the configured 404 phrase. The phrase must match text used on the site's not-found page. |
| Warning, log, info, debug | Browser console messages. Which levels are captured depends on the Console levels setting; new settings default to errors only. |
| Source location | Captured script or page location and, when reported, line and column. It can be missing or inherited from the issue's first report for older data. |
| Time into page | Approximate elapsed time on that page when the occurrence was captured. |
| Environment | Optional environment label supplied with the recorded diagnostic. It is not automatically a deployment identifier unless your site supplies one. |
| Replay this moment | Opens the retained recording at the recorded time when a playable matching session exists. |
The Recent errors view starts with JavaScript errors, network failures, not-found pages, and warnings selected by default. Grouped errors starts with JavaScript errors, network failures, and not-found pages. Other report views start with JavaScript errors. You can adjust the type selection; an empty selection means all supported types.
Problems and fixes #
- No Experience menu or an access screen: confirm you are signed in to the correct site and account. Experience has plan and account access gates; ask the site owner if the account should have access.
- No new visits or errors: check that the Hitsteps code is installed on the affected page, session recording is enabled, and Error tracking is enabled. Check the capture origin and page include/exclude rules.
- You see heatmaps but no errors: heatmap-only capture disables error collection. It is not evidence that the page has no errors.
- A consent or privacy choice excludes the visit: excluded visits cannot supply an error event or replay. Do not weaken a privacy choice just to create a report row.
- Only some console messages appear: Console levels are selectable and default to errors only. Enable other levels only if they are useful; console text may contain information written by your website.
- A 404 is absent: confirm Not-found page detection is on and that its phrase matches the text on your site's not-found page.
- A replay is unavailable: the visit may not have been recorded, may still be processing, may have failed, or may no longer be retained. The error details can remain useful without a replay.
- A page or browser report looks empty: clear filters, widen the date range, and check the selected error types and issue statuses. The default period is 14 UTC calendar days.
- A source line does not reproduce the issue: compare the captured page, browser, environment, and occurrence time. Source locations may be missing or may reflect the first occurrence for legacy data; the report does not fetch or execute the page's source code.
- An issue returns after resolution: a later matching event can appear again. Resolution is a tracking state, not a code change.
Access, privacy and limits #
Error diagnostics can include error messages, stack traces, source paths, page URLs, environment labels, browser and device information, and request metadata such as status, method, type, action, or duration when reported. Website code can put sensitive text into an error message or console call. Review those messages before copying or sharing them.
Error tracking depends on recorded visits and uses the same Experience capture and access boundaries. Experience settings provide recording retention choices, but the exact retained period available to a particular account depends on its current settings and plan limits. This chapter does not promise a fixed error-history period. The report describes its totals as applying across retained recordings.
Site owners control capture settings. Invited users must have access to the site and Experience reports; the available actions depend on your assigned permissions. Sharing an occurrence creates a public-to-link holder view of selected diagnostic details. Do not place personal data in error messages, console messages, or environment labels, and do not share an occurrence link unless its contents are appropriate for its recipients.
Last checked #
Checked 8 November 2026 using product documentation and source, with public pages and safe sample screens where available. Account-specific access, provider controls and effective limits can differ; use the current message shown for your website. Examples are illustrative.