Events arriving without a release: wire it up properly
Errors arrive untagged, or every deploy shows the same release. The SDK only tags events with the release you set — here is how to set it right.
What this looks like
You expect to compare errors per deploy — which release introduced this crash, which one fixed it — but events arrive with no release at all, or every event carries the same stale value across many deploys. Per-release grouping, regression visibility, and source map resolution all depend on this one field.
There is no auto-detection here by design: the SDK tags events with exactly the release you set in init or config (the release option, or allstak.release in property-based SDKs). If you never set it, events ship untagged; if it is hardcoded, it never changes.
Common root causes
Release never set in init
The release option is optional in every SDK — leaving it out means events arrive without one. Nothing infers it from git or your package version on your behalf.
Hardcoded or stale value
release: 'v1.0.0' written once in code stays v1.0.0 forever. The value must come from a CI variable that changes with every deploy.
Env var missing where the build runs
Frontend SDKs read the release at build time (e.g. NEXT_PUBLIC_RELEASE, VITE_ALLSTAK_RELEASE). If CI does not export the variable into the build step, the SDK gets undefined and sends nothing.
Changed without a restart or redeploy
The release is read when the SDK initializes. Changing the variable on a running process does nothing — the new value applies after a restart or redeploy.
Step-by-step diagnosis
Trace the release value from CI to the event — it breaks at exactly one link.
- 1
Check what a recent event carries
Open a fresh event in the dashboard and read its release field. Missing means the SDK never received a value; a stale value means the pipeline stopped updating it.
- 2
Confirm release is set in SDK init
Check your init/config for the release option — release: process.env.ALLSTAK_RELEASE in JS SDKs, allstak.release in Spring Boot properties, ALLSTAK_RELEASE in Laravel's .env, and the equivalent in your stack's setup guide.
- 3
Feed it from CI
Export the value in your CI pipeline — the git commit SHA or a version like [email protected] — into the variable your init reads. The same variable should drive your source map upload, so both always match.
- 4
Mind build-time vs runtime
For browser bundles the variable must exist during the build (NEXT_PUBLIC_*, VITE_*); for servers it must exist in the runtime environment at process start. Verify it is present in the right phase for your stack.
- 5
Redeploy and verify the tag
The release is fixed at init, so redeploy (or restart) and trigger a test error. Confirm the new event carries the expected release string.
- 6
Watch release grouping appear
Release-based grouping shows up once events carrying that release arrive — there is nothing to pre-register. From then on you can compare error rates across deploys and spot regressions per release.
Prevent it from recurring
- Make the release variable a required CI export — fail the pipeline if it is empty.
- Use one variable for both SDK init and source map upload so they can never drift apart.
- Prefer the commit SHA — it is unique per deploy and needs no human bookkeeping.
- Check the release field on one event after every deploy as part of your rollout routine.
Still stuck?
Each SDK setup guide documents the exact release option name for your stack. If the value is set in init, the variable is present in the right phase, and fresh events still arrive untagged, email [email protected] with your SDK, its version, and a link to one affected event.
Frequently asked questions
Does AllStak detect my release automatically?
No — the SDK tags events with exactly the release you set in init or config. Set it from a CI variable (commit SHA or version) so it updates with every deploy.
Can I change the release while the app is running?
No — the release is read at SDK initialization. Changing it requires a restart or redeploy, which matches reality anyway: a new release means new code is running.
What format should the release string use?
Any unique-per-deploy string works: a git commit SHA, a semantic version, or a combined form like [email protected]. Pick one convention and use it consistently across SDK init and source map uploads.
Why does the release matter for source maps?
Source maps are matched to events by the exact release string. An untagged or mismatched release means minified browser frames never resolve — see the source maps troubleshooting page.
Explore more
Capabilities
Compare
Know which deploy broke it
Tag every event with its release, compare error rates across deploys, and resolve minified frames with matching source maps. Start free.