EngineeringScoreSentry
Sentry catches the exceptions real visitors hit, folds them into one issue with a stack trace, and names the commit most likely behind it.
Why our report names it
Our scan opens your page once and reports what the console printed and what threw during that one load. An exception on the third step of a checkout, in a browser we did not drive, is outside anything a passive read can reach, so the report asks for error monitoring instead and names Sentry. We also run it, in this frontend and in the API behind it, which is why the honesty column below includes something we hit rather than something we read.
What it doesn't do
- It reports what your code threw. A page that renders the wrong total, or serves a stale cache, or silently drops a form submission, throws nothing at all, and no amount of error monitoring will raise its hand.
- Every event is charged against a quota. Sentry's quota documentation says outright that events beyond it are not accepted, that spike protection begins dropping events once volume passes a computed threshold, and that an SDK sample rate limits what is sent before any of that. A search returning nothing is not proof nothing happened.
- Its scrubbing covers the fields it knows about, and we found the edge of that here. Turning off default personal data leaves the URL path untouched, Sentry's own guidance concedes the SDKs may not parameterise every route, and our owner links carry a credential in the path, so `src/lib/sentry-redact.ts` strips it in `beforeSend` before an event leaves the process. Read your own URL shapes before trusting the defaults.
- Readable production traces mean uploading source maps on every deploy, which puts a build-time auth token in your pipeline. Sentry's SvelteKit guide notes development builds generate none, so a clean trace on your laptop is no evidence the upload is wired up.
What it does
- Sentry's Issues documentation sets out the model, and the model is the product: an application emits events, events sharing a fingerprint collapse into one issue, and a fault firing thousands of times reads as one problem with a count of affected users beside it.
- Triage is a state machine rather than a list. Unresolved, for review, regressed, archived and escalating are distinct states in Sentry, and a resolved issue that comes back is a regression with its own status instead of a fresh ticket nobody connects to the old one.
- The SvelteKit SDK generates and uploads source maps during a production build, which is what turns a minified frame into a line of your own code, and Sentry's suspect-commits feature attaches the most recent commit touching that line to the stack trace.
More on the problem
Nothing here is gated behind us. Go straight to Sentry and make your own mind up.
Sources
Every claim about Sentry on this page was read on from the pages below. Products change and this page does not change with them, so treat the date as the claim's expiry rather than its publication.
- Sentry's Issues documentation: that events are grouped into issues by fingerprint, that error and performance issues are the two categories, the triage states an issue moves through, and that suspect commits surface the most recent commit in the stack trace
- Sentry's billing quota documentation: that events exceeding a quota are not accepted, that spike protection drops events once volume passes a computed threshold, and that an SDK sample rate limits what is sent
- Sentry's SvelteKit source maps guide: that the SDK generates and uploads source maps during production builds, that development builds generate none, and that the upload needs an auth token in the build
- Sentry's guide to scrubbing sensitive data: that a raw URL can carry personal data in its path and that the SDKs may not manage to parameterise every route
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.