Release Tracking

Why track releases

Without a release, ErrTap cannot tell whether an issue is new or a regression. When you attach a release string to events:

• Issues that were resolved in one release automatically reopen if the same error fingerprint appears in a later release.
• You can filter the issue list by release to see what broke in a specific deploy.

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>@your-host',
  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: DSN et_<your-key>" \
  -H "content-type: application/json" \
  -d '{
    "version": "1.4.3",
    "environment": "production"
  }'

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

Regression behaviour

1. Issue XYZ is resolved (manually or after a quiet window).
2. The same error fingerprint appears in a later release.
3. ErrTap transitions the issue from resolved → open and marks it as a regression.
4. Alert rules for REGRESSED_ISSUE fire on configured channels.