Compare releases

Releases connects captured storefront release identifiers and merchant release markers to changes in issue activity. Start with a release in the history, then inspect its active period and early impact. Timing provides an investigation lead; it does not prove that a release caused a change.

Separate early impact from release lifetime

Current release: its active period continues from the release marker to now, until the next release.
Historical release: the next strictly later marker closes the active period. Recent evidence can still be settling before the saved lifetime is complete.
Early impact: covers up to the first seven days, shortened when another release arrives sooner. The baseline covers the same duration exactly one week earlier.

If a release stays current for 15 days, its lifetime covers 15 days while its early report covers seven. If another release arrives after three days, both active and early periods end after three days; the early baseline is also three days. Seven days is an early signal boundary, not a cap on the release’s life.

Read each panel’s scope

Daily lifetime history preserves additive event, page-view and error counts. Missing days remain visible as gaps. Available daily session counts are not added into a lifetime unique-session total. A quiet day with a captured zero is different from a day without saved evidence.

Performance compares exact-release measurements at equal release age. The journey, request and exposure panels describe their labelled retained-version scope; they are not automatically durable lifetime snapshots. Older tabs can still emit an old release tag after a new deployment, but those events do not extend the old release’s closed active period. Legacy seven-day reports remain labelled and accessible.

Follow a change into investigation

Look for issues first observed after a release, returning issues and changed occurrence activity. Inspect the linked issues and affected sessions. A slower LCP is a performance investigation lead; check its sample readiness and use Performance for the wider picture.

When no complete history or usable sample is available, the missing evidence stays explicit. A saved report is an observation of its stated window, not a claim that every shopper or late event was captured.

Mark releases from CI

Mark each deployment from the pipeline that ships it. Create a CI credential in Releases → Source maps, store it as the masked DOZENFOLD_SOURCE_MAP_TOKEN secret, then run this after the deploy:

npx dozenfold releases create \
  --release "git-$GITHUB_SHA" \
  --shop example.myshopify.com \
  --note "Deploy $GITHUB_SHA"

In GitHub Actions, use Dozenfold/cli@v1 with command: release; see Source maps. The marker starts the release’s active period and new storefront events carry its identifier. Re-running the command for the same release moves its marker to the new time. A release identifier is 1–128 characters of letters, digits and ._:@/+~-.

Connect source maps

Open Releases → Source maps to associate a deployment with its private build artifacts. CI is the recommended path for recurring releases; an Owner-only manual upload is available for one published Shopify build. Continue with Source maps for the inject, upload, publish and CDN verification sequence.

Interpret responsibly

Traffic mix, browser distribution, campaigns and other storefront changes can move at the same time. Confirm the issue fingerprint and affected journey before reverting code. After a fix, watch for recurrence with relevant traffic instead of treating a quiet interval as proof of recovery.