Release health

Deploys are the most common self-inflicted incident. Without a version on the event, you cannot ask “did 1.4.2 make this worse?” You can only ask “is production loud right now?” Those are different on-calls.

The problem

Git tags live in the repo. Users live on 1.4.1 for a day after you ship 1.4.2. Crash-free session rate, adoption, and “new in this release” are how you notice a bad build while both versions are still in the wild. A single error count for the project hides that split.

What it is

Release health is an aggregation of events (and sessions, where the SDK provides them) by release string. For each version Talaria shows crash-free session rate, user count, error count, new issue count, commit SHA, and first seen. A release is not inferred from the server clock — you set it on the SDK or register it from CI.

What it gives a team

• A go / no-go after deploy that is not a vibe check on Slack.
• Suspect versions before suspect commits: if new issues cluster on 1.4.2, bisect that tag, not the whole week.
• Source context on frames when GitHub is connected — the line of code at that SHA, not HEAD.

How Talaria does it

Every event can carry release and commitSha. CI can register versions via SourceEndpoint.createProjectRelease with a releasesWrite key. The Releases page calls listReleaseHealth and aggregates from the event store.

GitHub: org-level app install, per-project repo mapping, commit-exact file slices on primary frames. Capistrano-style paths can yield a SHA from the stack when you did not pass one. This is source context, not a symbolication worker for minified bundles or native crash dumps.

How to read it

• After a ship, watch crash-free and new issues on the new version — not only total error volume.
• Open an issue that first appeared on that release and jump to a trace if traceId is present.
• Compare RED in the same window. A crash-free dip with a p95 spike is a performance regression that also throws; a crash-free dip with quiet RED is likely a client exception path.

Turn it on

Set release (and commitSha if you have it) in SDK init — the same field on PHP, browser, Dart, and Flutter. Optionally register the release from GitHub Actions so the dashboard has a row before the first event. Connect GitHub in project settings for frame context.

What this is not

Talaria does not yet treat suspect commits or CODEOWNERS as a first-class assignment engine. There is no source-map upload worker. Flutter native crash dumps are out of scope. Adoption curves need events tagged with the new release — untagged traffic will not appear in the version split.