Errors group by their mapped source automatically, on every platform. There is nothing to configure: upload symbols or source maps, and the same error in a new build joins its existing issue.
Native crashes on iOS, tvOS and Android are grouped by the mapped function once their dSYMs, R8 mappings or native libraries are uploaded. A crash whose top frames have no mapped line keeps an issue per build for now. See Symbols & source maps for the uploads.
Web and React errors
Web and React errors are grouped by function once their build’s private source
maps are uploaded. Everframe takes the first frame in your
own code (skipping browser-native frames and library code such as
node_modules or react-dom) and keys the issue on that frame’s original file and function,
so an edit that moves the function keeps one issue across builds. The function is
identified by its name and the functions, classes or objects it sits in (two
local save functions inside cart and user are different issues), read from
the source text the source map carries. When the map has no source text, the
source file is very large, the function is anonymous, or the file holds two
functions with the same name in the same place, the issue keys the exact
original line and column instead, so
different functions never share an issue.
Until its maps are uploaded, an error is grouped by the client fingerprint, as
it would be without source maps. It stays that way when a frame above your first
mapped frame could be your own code but cannot be identified (eval or blob:
code or a script without an uploaded map), so separate failures are never merged
under a shared caller. The file is the source path exactly as your source map
records it, so a project whose bundler writes the same paths in every build keeps
one issue per function across builds. When the maps arrive, the error moves to its
source issue. Grouping by source needs an exact appBuild on the captured
report and a ready upload for that app and build.
Issues created by the earlier per-app web grouping setting, which keyed exact lines, keep their grouping; only new errors use function keys.
Promotion preserves the captured report, Raw stack, report ID, webhook history, and total occurrence count. Emptied per-build issues remain available through their direct authorized URLs with grouping movement history. Manual merge and split cover issues grouped by the client fingerprint; issues grouped by web source location do not support them yet.
Register release order
Release-aware resolution is available only for a positive-count mapped issue owned by one Web or React integration.
Open the integration overview and use the Releases card. An organization administrator registers:
- Build ID: the exact opaque value sent as SDK
appBuildand CLI--build. - Release order: a unique positive integer from 1 to 2,147,483,647.
Higher order means newer. Everframe does not infer order from semantic versions, build names, report arrival, source-map upload time, or registration time. Uploading maps does not register a release. Register each build before relying on its classification.
The current registry has no edit or delete action. You can register an older build later with a lower unused order, but registration does not rescan earlier occurrences. Parallel environments or release streams need separate integrations.
Mark a mapped issue fixed
Open the mapped issue, choose a registered build under Fixed in release, then select Mark fixed in release. Project members and administrators can mark the issue fixed.
Future mapped occurrences received after that action behave as follows:
| Occurrence build | Result |
|---|---|
| Registered below the fixed release order | The issue stays resolved and its count increases. |
| The fixed release or a higher registered order | The issue reopens as unseen and shows Regressed. |
| Not registered | The issue stays resolved; the uncertainty count increases. |
| Report received before the fix, mapped afterward | The issue stays resolved. |
The fixed release itself can regress: choosing it means another occurrence from that build is unexpected. The comparison uses server receipt time and explicit release sequence. Device clocks and semantic-version parsing are not involved.
Registering an unknown build later does not rewrite the current cycle. A future occurrence uses the registry available at that time. Missing build identity or maps can leave a report provisional, where it cannot be evaluated against a mapped issue’s fixed release.
Ordinary Resolve and Unresolve remain available and clear the selected release policy. Only the current release-resolution cycle is retained; this is not a complete regression audit timeline.
Send regression webhooks
An organization administrator can enable Regression alerts when creating a webhook subscriber or from that subscriber’s actions. The setting defaults off and applies only to future qualifying release-aware regressions.
Everframe sends a signed issue.regressed event through the existing durable
webhook queue. The event contains app, project, issue, event, report, resolution,
and fixed/regressed release identifiers and sequence numbers. It does not
contain the report body, exception message, source code, attachments, or user
identity.
Verify the standard webhook signature against the raw request bytes. Use the
event’s top-level id as the durable deduplication key: every subscriber and
retry for one resolution cycle receives the same logical ID and body. Delivery
is at least once; X-Everframe-Delivery-Id identifies one subscriber queue row,
while X-Everframe-Attempt changes across retries. See Webhooks
for signing and retry behavior.
Enabling alerts does not register releases, mark an issue fixed, or replay past regressions. Inbox/email delivery, native release policies, ownership, snoozing, automatic historical grouping, and optimized generic-cause presentation are outside the current completed scope.