Releases

The release option tags every event and error with the version of your app that produced it. This lets you compare error rates between deploys, see which version introduced a bug, and track whether a fix actually resolved an issue.

Setting a release

Pass release to init(). Any string works — semver, git SHA, or a deploy ID:

import { init } from "@emit-vision/sdk-js";
 
init({
  apiKey: process.env.EMIT_VISION_API_KEY,
  release: process.env.APP_VERSION ?? "dev", // e.g. "2.4.1" or "abc1234"
  environment: "production",
});

Good sources for the release string:

What you see in the dashboard

The Releases tab shows:

• Each unique release value seen in the last 30 days
• New errors — errors first seen in that release
• Resolved errors — errors from a previous release not seen since
• Error rate — events-to-errors ratio for the release period
• Adoption — what fraction of sessions are on the new release

Release-aware error grouping

In the Errors tab, every error group shows:

• First seen in — the release where this error was first captured
• Last seen in — the most recent release where it appeared
• Affected releases — all releases where at least one occurrence was recorded

This lets you verify that a bug fix actually worked: if the error's "last seen in" matches the release before your fix, it's resolved.

What changed this release

Open a release from the Releases tab to see how it moved the numbers compared with the release before it. The same verdict appears on the compare page and in the weekly digest.

How the baseline is picked

The baseline is the previous release by first-seen time in the same environment. A release that has only run in staging is never compared with one from production. Use Compare against to pick a different baseline.

Aligned windows

Both releases are measured over the same length of time from the moment each one first appeared, so a release that has been live for a week is not compared with a few hours of the new one. The window is capped at 7 days. The page states the exact window it used, for example "Comparing the first 3d of each release."

When there is no number

• Too early to compare — the release has been live for less than 1 hour, so nothing is calculated.
• First release in this environment — there is no baseline. You still see health and error movement for the release, but no comparison.
• Not enough sessions yet — a rate needs at least 50 sessions in both windows. Below that the dashboard shows the session count instead of a percentage, because a rate from a handful of sessions is noise. A dash means the data is not available.

Error movement

Each error group is placed in one of four categories:

Each list shows up to 10 groups. Each row links to the error group, filtered to the release and environment.

Segments

Most affected segments (browser and country) show each segment's error-session rate before and after. Contribution is how much the segment's share of all error sessions moved between the baseline and this release, in percentage points. A large positive value means errors are concentrating in that segment. It is blank when there is no baseline. Segments with fewer than 50 sessions are left out.

In the weekly digest

The weekly digest lists up to three production releases first seen that week, each with its verdict, error-session and crash-free changes, the top new error, and a link to the full page. Releases that are too early show "Too early to compare".

What changed on the Overview and Errors pages

The Overview page has a What changed panel that compares the last 24 hours (or the last 7 days) with the period right before it, in the selected environment. The Errors page shows the error-related callouts from the same comparison above the error list, labelled with the period they cover. The 24h/7d toggle on Overview sets changes= in the URL; on Errors the period follows the date range, with ranges up to 36 hours using 24h and longer ones 7d.

Why the previous period

A callout says something moved, so it needs something to move from. Comparing with the immediately preceding period of the same length avoids time-of-day and weekday mismatches between the two windows. Release callouts use the aligned release windows described above instead.

What triggers a callout

• Rates (sessions with errors, crash-free sessions, affected users) need at least 50 sessions in both periods. They are flagged when the rate moves by at least 1 percentage point and at least 25% relative to the earlier value. Twice those thresholds makes the callout Critical.
• Error groups are flagged when they are new, reappeared or worsened and appear in at least 1% of sessions. A new error in 5% of sessions or more is Critical. Groups that were active in the earlier period and disappeared are shown as improvements.
• Key events are flagged when their session rate moves past the same rate thresholds.
• Segments are flagged when the overall error rate moved and a browser or country is a large contributor to that movement.

At most five callouts are shown, most severe first. Each links to the error group, the filtered Errors list or the event it describes.

Why nothing was flagged

Nothing moved significantly means no change cleared its threshold. It does not mean nothing changed. Small shifts, and rates based on fewer than 50 sessions, are left out on purpose, because a flag from a handful of sessions is noise. No traffic in this period means there were no sessions to compare.

Pinned key events

By default the 8 busiest events are compared. To compare specific events instead, add them under Settings → General → Key events. Pinned events are compared even when they had no traffic in a period, so a drop to zero is visible. Callouts and the release page both use the pinned list.

Node.js

Set release in the Node SDK the same way, typically from an env var populated at deploy time:

import { init } from "@emit-vision/sdk-node";
 
init({
  apiKey: process.env.EMIT_VISION_API_KEY,
  release: process.env.APP_RELEASE ?? "local",
  environment: process.env.NODE_ENV ?? "development",
});

Per-event overrides

If you need to tag a specific event with a different release (e.g., a background job running an older version), pass it in options:

import { captureEvent } from "@emit-vision/sdk-js";
 
captureEvent(
  "migration_completed",
  { version: "v3" },
  {
    release: "[email protected]",
  },
);

This overrides the global release for that single event only.