Monitoring
Releases
Most incidents start with a deploy. Releases group your production data by the version that produced it, so "did we break it?" is a question you can answer rather than argue about.
Release health
Compare error rates before and after a deploy. A release that introduced a regression shows it immediately, without you correlating timestamps by hand.
Suspect commits
For an issue with resolved symbols, Octri maps the failing frames back to the commits that last touched those lines and surfaces the most likely culprits.
An issue in checkout.ts:214 where that line changed two hours ago in one commit is a very short investigation.
Suspect commits are derived from resolved frames. Minified frames point at a.b.c, which never touched a commit, so the section stays empty. Upload symbols for every release, not just the ones you're currently debugging. See Symbolication.
The release id
A release is whatever string your SDK reports at runtime through logging.release. The git SHA is the right choice: it's unique, it's already in your CI, and it maps to a commit.
Your SDK reports a release. Your CI uploads symbols for a release. If those two strings differ, monitoring has data under one id and symbols under another, and it will never join them.
Both should be $(git rev-parse HEAD).
What to do with it
- Deploy
Your app reports its release with every event.
- Upload symbols for that release
From CI, at build time, before the artifacts are discarded. See CI setup.
- Watch the new release
Error rate and latency against the previous one.
- Roll back on a regression
Facet the issue by release to confirm the rollback actually stopped it.