Monitoring

Releases page

Set release on your SDKs and register releases and deploys from your pipeline (see Releases and source maps). The Releases page then shows how each version is doing, which commits probably caused an issue, and who owns the code.

1Release health

Per release: adoption (share of the project's sessions), crash-free sessions, crash-free users, events, new issues, regressions and the last deploy. Rates are floored so one crash never shows as 100%. Sessions come from Sentry SDKs, from POST /api/v1/sessions, or from the browser SDK with autoSessionTracking: true and a release. Sessions are kept 90 days.

2Suspect commits

An issue page lists up to five commits from the first release the issue appeared in whose changed files match an in-app stack frame (the last two path segments must agree, so upload source maps for minified bundles). Commits come from the GitHub compare API when a token is saved, otherwise from what the CLI sent.

3GitHub token

Save a token per project on the Code owners page. It is encrypted, only a 4+4 character hint is ever shown, and it is used only against api.github.com.

4Code owners rules

A rule maps a file-path glob or a URL pattern to an email or a team label such as #payments. Path globs: src/checkout/**, *.py, models/*.py; * stays inside a directory, ** crosses directories, and a pattern matches at any directory boundary. URL patterns like */checkout* are case-insensitive. At most 4 wildcards and 256 characters per pattern, 200 rules per project. Matching owners show on the issue page, and owners that are emails get alert copies.

ini

src/checkout/**      ana@example.com
models/*.py          #odoo-team
*/checkout*          payments@example.com

Good to know

Regressions on the Releases page count issues that were resolved and came back in that release.
Crash-free users needs sessions with a user id; aggregate session counts have none.

Stuck? Email support@blipit.io. Keys and the exact DSN for each project are under API keys in app.blipit.io.