Release tracking

Tag your events with a release string and tinymon shows you which version an error first appeared in, every release it's turned up in since, and automatically flags regressions when a fixed bug comes back.

Set the release string

Pass release to init() in the SDK, and use the same string when you upload source maps at deploy. A short git SHA or a semver tag both work well — whatever you use, keep it identical across the SDK and the deploy step so maps and releases line up.

// JavaScript / TypeScript
init({
  dsn:         process.env.TINYMON_DSN,
  environment: 'production',
  release:     process.env.RELEASE,  // e.g. git short SHA
});

# Python
tinymonpy.init(
    dsn=os.environ['TINYMON_DSN'],
    environment='production',
    release=os.environ['RELEASE'],
)

# Ruby
Tinymon.init(
  dsn:         ENV['TINYMON_DSN'],
  environment: 'production',
  release:     ENV['RELEASE'],
)

If you don't set a release, errors are still captured — you just won't get first-seen or regression information for them.

First seen & issues per release

The first time an error's fingerprint is seen, tinymon records the release it appeared in as that issue's first seen in. As the same error recurs across deploys, it tracks every release it shows up in, with a per-release event count. The issue detail page lists them; a project's Releases page rolls it up per version — how many issues were new in each release and how many regressed in it.

Filter by release

The issue list filters by release: pick a version and you'll see the issues that have appeared in it. (See Search & filter for the rest of the filters.) From the Releases page, the new- and regressed-issue counts link straight into that filtered view.

Regression auto-reopen

This is where releases earn their keep. When you mark an issue resolved, it goes quiet. If that exact error fires again afterward, tinymon:

• automatically reopens the issue (status back to unresolved),
• marks it regressed in the release it came back on, and
• sends a regression alert through your channels.

Ignored and silenced issues stay muted — only a resolved issue regresses. So a fix that quietly breaks again in a later release won't slip past you, and you don't have to remember to watch for repeats.