DEVELOPER EVIDENCE & SOURCE MAPS

Less back-and-forth.
A better place to start.

Bring the error, observed path, environment and source context into the same conversation. Give the person shipping the fix something concrete to work with.

The handoff has a trail behind it.

Start with a captured occurrence. Keep its request, environment and original source connected as you prepare the next action.

northstar / developer evidenceSelected 30 days

SELECTED OCCURRENCE · MOBILE SAFARI

From the observed path to original source.

  1. Product viewed/products/ridge-jacket
  2. Delivery option changedCaptured storefront action
  3. Cart update failedPOST /cart/update · TypeError
storefront@2.18.4Mapped source

Cannot read properties of undefined

cart.ts:184

182  const rate = rates.find(matchRate)
183  setPending(true)
184  rate.handle
185  await updateCart(rate)
Original source when a usable source map is uploaded.
Keep the occurrence, environment and source together.
Illustrative product data Explore freely. No store connection required.

KEEP THE INVESTIGATION MOVING

The next question
already has a path.

Read the product guide ↗
01

Choose an occurrence worth opening.

An issue can appear in more than one environment or path, and the same error stays one issue across deploys. Inspect selected captured examples with their timing, browser, release and breadcrumbs, and see the likely owner: your theme, Shopify, a third-party script or a browser extension. With error-session replay turned on, a masked recording of the minute before the error and the rest of the session plays beside the session timeline. Keep the source context tied to the occurrence and frame you are actually investigating.

Choose an environment to investigate
02

Get from the stack to your code.

Upload source maps for the matching release to resolve minified locations to original source, including the linked causes of an error. Third-party callbacks are wrapped so fewer failures arrive as an opaque “Script error.”, and handled errors can be reported with captureException. Inspect frames and surrounding code alongside the observed error. The request and session timeline provide context for the developer to establish how the events relate.

Explore captured session evidence
03

Take the evidence into your workflow.

Open the Developer brief as a prefilled Linear or GitHub issue, copy it for your developer or a coding assistant, or connect the assistant directly through MCP so it can read the issue, session and release evidence itself. Share the stack, selected source context, environment and observed path in one handoff. Once the team ships a change, return to the issue and release evidence to see what happens next.

Follow the change after deployment

A LITTLE MORE DETAIL

Good questions.
Useful answers.

What is in the Developer brief?

The selected error and technical context: occurrence details, environment, stack, usable mapped source and the captured path leading to the failure. The public example is downloadable so you can review the format before connecting a store.

How do original source locations become available?

Upload a usable source map for the matching release. The selected stack frame can then resolve from a minified asset to its original location and source context.

Can I watch what happened before the error?

Turn on error-session replay in Settings. Only sessions with an error upload a masked recording: the minute before the first error, then the rest of the session until the shopper goes idle, for up to 30 minutes. Inputs are always masked and page text is masked by default. The replay opens from the issue beside its session timeline.

Can I send the brief to Linear or GitHub?

Yes. Create Linear issue and Create GitHub issue open your tracker with the brief filled in, under your own sign-in, and you choose the team or repository there. Dozenfold stores no tracker credentials.

Can I use the brief with my coding assistant?

Yes. Bring the portable brief into your existing development workflow as investigation context. Your team owns the diagnosis, code change and review.

Can my AI tools connect directly?

Yes. Create a read-only MCP key under Settings → AI agents and add it to Claude Code, Cursor or another MCP client. The tools return the same issues, sessions, releases and revenue estimates you see in the dashboard. We are also building Dozenfold’s own AI reliability engineer to investigate problems, work on fixes and follow outcomes within your permissions.

CONNECTED PRODUCT WORKFLOWS

Follow the next connection.

An issue, a journey, a page or a release. Each view gives you a way into the next.

PUT YOUR STOREFRONT IN FOCUS

Your store.
Your next useful fix.

Bring the shopper journey you want to improve and the person who ships your changes. We’ll connect the first evidence and work through the findings together.

Book a demo Estimate your price and contact us · Guided setup

DF-1876 / REVENUE EVIDENCE

A priority you can look into.

Cart update fails after a delivery change

Measured loss$18,420One issue · Selected 30 days · USD

Illustrative calculation.
No live store connected.

486Affected sessions
480Compared with clean sessions
9,720Clean sessions

What happened after the failure?

Affected sessions hit the failure within 30 minutes of entering a journey stage. Clean sessions reached the same stage on the same device and environment without this issue. Purchases count in the same 30-minute window for both.

With this issue10%48 / 480 purchased
Clean sessions34%Same stage, device and environment mix
The interval decides the label.

The pooled gap is 24.0 percentage points with a 95% interval of 21.2–26.8 points. The whole interval is above zero, so the loss is measured. Strata where affected shoppers converted better pull the gap down instead of being ignored.

See the inputs and calculation

480 compared sessions × 24.0% conversion gap = 115.2 missed purchases × $159.90 clean average order value ≈ $18,420.

The order value uses complete clean-session orders in USD. This example has uniform, full capture. The 6 affected sessions without a comparable clean group are not priced.

This estimates a difference associated with the issue. It does not identify confirmed lost orders or establish cause. The selected 30 days are the evidence scope, not a monthly projection.

Read the complete methodology ↗

DF-1876 / DEVELOPER HANDOFF

Take the evidence with you.

A technical brief for your developer or coding assistant. Review it here, then copy or download it into your own workflow.

Illustrative issue · No shopper identity or revenue figures
# Dozenfold — example developer brief

Illustrative product-tour data. This is a fictional issue, not a customer incident.
Use it to see the kind of evidence you can take from Dozenfold into your team's workflow.

## Issue

DF-1876 — Cart update fails after a delivery change

- Error: TypeError: Cannot read properties of undefined
- Observed environment: production, Mobile Safari
- Release: storefront@2.18.4
- Affected surface: storefront cart delivery selector

## Observed journey

1. 12:41:58 — Viewed /products/ridge-jacket
2. 12:42:11 — Added a variant to the cart
3. 12:42:46 — Changed the cart delivery option
4. 12:42:47 — POST /cart/update failed; TypeError captured

These are captured events, not a screen recording or a guaranteed reproduction.
No shopper identity, typed value, request body or response body is included.

## Original source context

Available in this example because a usable source map was uploaded.

```ts
// cart.ts:184 — illustrative source
const rate = rates.find(matchRate);
setPending(true);
rate.handle; // captured failing line
await updateCart(rate);
```

## Investigation starting point

Inspect how the delivery selector handles a missing matching rate. Check the captured browser
and release context against your implementation. The evidence locates an observed failure;
it does not establish its root cause or prescribe an automatic fix.

## Product guides

- Developer evidence: https://docs.dozenfold.com/docs/developer-evidence
- Source maps: https://docs.dozenfold.com/docs/source-maps
- Sessions and journeys: https://docs.dozenfold.com/docs/sessions-and-journeys

The live product's brief is scoped to the selected issue and occurrence. This public example
contains no live investigation link and no financial estimate.

DF-1876 / CLIENT REVIEW

A decision you can explain.

Client review: cart delivery update

Northstar Outdoor · DF-1876 · Selected 30 days

Illustrative working example prepared for a client conversation. This is not a customer result or an automatically generated client report.

The decision

Prioritize investigation of the cart delivery selector with the team responsible for the storefront. Shoppers changing a delivery option encounter a recurring failure, concentrated on Mobile Safari in storefront@2.18.4.

Why this issue

  • 486 affected sessions in the selected period.
  • $18,420 measured revenue loss, associated with this issue in USD.
  • 480 affected sessions were compared with clean sessions at the same journey stage, device and environment. Within the same 30-minute window, 10% of affected sessions purchased against 34% of clean sessions.
  • The pooled gap is 24.0 points with a 95% interval of 21.2–26.8 points, entirely above zero. About 115 missed purchases are valued at the $159.90 clean average order value. The 6 affected sessions without a comparable clean group are not priced. This is not confirmed lost revenue or a store-wide total.

Inspect the example calculation

The proposed next step

The storefront developer investigates the delivery selector using the observed journey and uploaded source map at cart.ts:184. Check how a missing matching delivery rate is handled; the evidence does not yet establish the root cause.

The technical brief carries the stack, environment and source context. It deliberately excludes financial estimates so it can be shared in the developer’s own workflow.

Open the technical investigation

What we will review after a fix

Record the actual deployment and look for this issue on the new release, including relevant traffic and browser coverage. If it recurs, reopen the investigation. An absence of errors without observed activity is not evidence of a successful fix.

Current status: investigation proposed. No fix, recovered revenue or post-fix outcome is claimed in this review.

DOZENFOLD / PRIVACY

Make yourself at home.