Skip to content

Features

Release health: know if a deploy made things worse

An error count alone does not say how bad a release is. Sessions give errors a denominator: the share of visits and users that went through without a crash, for every version you ship.

All Buglapse features

Release health

Stability you can compare between releases

  • Crash-free sessions and users

    The share of sessions that did not crash and the share of users none of whose sessions crashed, per project and per release.

  • New issues per release

    Each release page lists the issues first seen in it, with event counters and the commit it was built from — the deploy that broke something is easy to find.

  • Sessions cost nothing

    Sessions do not count toward any quota and are never sampled, so the crash-free numbers stay exact however much traffic you have.

  • An alert when stability drops

    When the crash-free rate of the last hour falls below the threshold, the team gets an alert — at most once a day per project.

How it works

Release health in three steps

  1. 1

    Nothing to enable

    The session integration of the browser SDK is on by default, with the script tag and the npm package alike.

  2. 2

    Set a release

    Pass a release and an environment to init — a version, a git commit or a build number — so the numbers can be compared between deploys.

  3. 3

    Compare versions

    Open Sessions for the overall picture and Releases to see every version with its crash-free rate and new issues.

main.ts
import { init } from '@buglapse/browser'

init({
  dsn: 'https://YOUR_PROJECT_TOKEN@app.buglapse.com',
  release: 'web@1.4.2',
  environment: 'production',
})

In detail

How sessions and releases work

What a session is

The browser SDK tracks one session per visit. It starts when the SDK initializes, survives reloads and new tabs on the same site, and ends after thirty minutes of inactivity. A session is healthy, errored when a handled error was reported, or crashed when an unhandled error occurred. An issue page also shows the share of sessions the issue occurred in since it first appeared, which tells how many visits a single bug really touches.

Releases tie everything together

The release string you set is stamped on errors, logs, spans and sessions. It is the same value that source maps are matched against, so a release page brings together the stability of that version, the issues it introduced and the files that have source maps. The first release of an issue never changes afterwards, which makes it clear where a bug came from even months later.

On each plan

Compare all plans
On each plan
Free Pro Team
Sessions (release health)7 days14 days90 days
Errors & issues14 days30 days90 days

FAQ

Common questions

Still have questions?

Drop us a line — we'll help with setup, plans or self-hosting.

Contact us

or email hello@buglapse.com

Do I need extra code for release health?
No extra integration is needed in the browser. Set a release in init and the crash-free numbers appear for it.
What is the difference between errored and crashed?
A session is errored when your code reported an error it handled, and crashed when an error was not handled at all. Only crashed sessions lower the crash-free rate.
Does it work for backend services?
Sessions are tracked by the browser SDK. Releases themselves work for Node.js too: set a release in init and every error is attributed to it, with the new issues listed on the release page.

See also

Error tracking

Every error grouped into one issue with a readable stack trace, breadcrumbs, the steps to the error and the affected users.

Learn more: Error tracking

Alerts

Alerts about new and returning errors, spikes, stability drops and downtime — by email, in Telegram and in MAX.

Learn more: Alerts

Ready to see what's happening in your app?

Create a project on the free plan and send your first event in a couple of minutes.

Still have questions? Email hello@buglapse.com