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

Or at boot:

ErrTap::configure(['release' => config('app.version')]);

Sending a release event

You can also notify ErrTap when a deploy lands, linking commit metadata to the release:

curl -X POST https://your-host/ingest/release \
  -H "Authorization: DSN et_<your-key>" \
  -H "content-type: application/json" \
  -d '{
    "version": "1.4.3",
    "ref": "a1b2c3d",
    "repository": "acme/backend",
    "commits": [
      { "id": "a1b2c3d", "message": "Fix checkout timeout", "author_name": "Alice" }
    ]
  }'

The release record appears under Releases and shows which errors were seen before and after the 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.