Release Tracking

Why track releases

Two things work together: the release string your SDK attaches to each event, and the release records you register for each deploy (with POST /ingest/release from CI, or Mark release on the Releases page). With both in place:

• A resolved issue reopens as a regression when the same error arrives from a release deployed after the one it was resolved in. See Regression behaviour.
• The issue page lists every release the issue appeared in.
• Stack traces are de-minified with the source maps uploaded for that release.

Release health

The Releases page lists every release, newest first. For each one it shows the issues it introduced, regressions, crash-free users while it was live, and events per hour compared with the previous release. Release health is included on Pro and above.

How to set a release

Pass release at SDK initialisation — any short string works: a semver, a git SHA, a CI build number.

Browser / Node.js:

import { init } from '@errtap/browser'; // or @errtap/node

init({
  dsn: 'https://et_<key>@<host>/<project>',
  release: '1.4.3',          // or process.env.APP_VERSION
  environment: 'production',
});

Laravel:

ERRTAP_RELEASE=1.4.3

Sending a release event

You can also notify ErrTap when a deploy lands:

curl -X POST https://your-host/ingest/release \
  -H "Authorization: Bearer $ERRTAP_AUTH_TOKEN" \
  -H "content-type: application/json" \
  -d '{
    "version": "1.4.3",
    "environment": "production"
  }'

The release record appears under Releases. Sending the same version again bumps its deploy time. Use the same version in SDK events to associate errors with that deploy.

ERRTAP_AUTH_TOKEN is an upload token from Project settings → Upload tokens. Releases drive regression detection, so they need this CI secret rather than the public DSN. Release records, whether from CI or the dashboard, need a plan with release health (Pro and above).

Regression behaviour

Issues are resolved by hand, from the issue page or in bulk; nothing resolves them automatically. When you resolve an issue, ErrTap notes the newest release record in the project (by deploy time) as the release it was resolved in. What happens when the error comes back depends on whether there was one:

• No release records yet. The next event for the issue reopens it as a regression, whatever release it carries.
• Resolved in a registered release. The issue reopens only when an event arrives with a different release that is also registered for that event's environment and was deployed later than the one it was resolved in. Events with no release, the same release, or a version you never registered leave the issue resolved; they are still counted.

A reopened issue goes from resolved to open, is marked as a regression, and alert rules for REGRESSED_ISSUE fire on configured channels. A snoozed issue that gets an event after its snooze ends reopens the same way.

Environments are matched by name, and a release registered without one counts as production.