dozenfold Docs Investigate issues
An issue groups repeated evidence with the same technical fingerprint. The issue list is a work queue, not a raw event log: it helps a merchant or developer decide what to examine first.
Find the right issue
Use the top views to switch between prioritized work, issues needing review, regressions, and the complete issue set. Search and filters are reflected in the URL so a filtered view can be shared.
Available filters can narrow the list by:
- status and priority
- journey stage
- production environment and release
- browser, device, operating system, and viewport evidence
- source or issue type
- recent activity and evidence readiness
Sorting lets you emphasize commercial impact, recent activity, affected sessions, newest issues, or regressions. An empty result means no issue matches the current filters; it does not mean monitoring has stopped.
Understand an issue
The detail page keeps three jobs distinct:
- Overview explains observed activity, revenue evidence, environment concentration, and the issue lifecycle.
- Reproduce shows the common journey, privacy-safe steps, affected anonymous sessions, and nearby friction or performance signals.
- Developer presents the normalized fingerprint, exception or request evidence, stack and source context, release evidence, and a technical handoff.
What is captured with an error
Besides uncaught errors and unhandled promise rejections, Dozenfold captures errors thrown inside
browser API callbacks such as timers and event listeners, and Error objects passed to
console.error. When an error has a cause chain or is an AggregateError, the linked errors are
kept with it and shown under the technical cause. With source maps, their frames are mapped too.
Errors your code catches itself are not reported automatically. To report one from a try/catch
or a framework error boundary, call window.Dozenfold.captureException(error) from theme or
storefront code; pass { severity: 'warning' } for a handled problem that is not an outright
failure. The call returns false and sends nothing before collection starts, without consent, or
while the same error is being throttled.
Grouping ignores deploy-specific details such as asset content hashes, theme ids and line or column shifts, so the same problem stays one issue across releases.
Where this error comes from
Some errors are not caused by the store’s code. The issue page shows the share of occurrences that came from a social app’s in-app browser (Instagram, Facebook, TikTok, Pinterest, Snapchat), from shoppers who were offline when a request failed, and from browser-extension code. When extensions or lost connections account for most occurrences, the page says so.
The Developer brief also names the issue’s likely owner: the installed app or script origin the failing code came from, when one was captured. Alerts and AI tools use the same owner classes: your theme, Shopify, a third-party script, a browser extension, or unknown. Theme code is yours to fix; a third-party script belongs to an installed app or external service.
These shares cover occurrences captured by current SDK versions; the page states how many of the issue’s occurrences carry this context. Environment concentration also includes country, connection type and device memory next to browser, device, operating system and viewport.
Dead-click candidates, rage clicks, repeated submits, and similar friction signals are supporting clues. They do not prove the issue caused a shopper action.
Manage investigation state
Mark an issue resolved when the underlying problem has been addressed. Ignore it when the grouped signal is expected or not actionable. A later recurrence can be surfaced as a regression so it is not silently mixed into the old investigation.
For the commercial labels used on an issue, see Revenue impact methodology.