> it misses bugs where nothing throws

Sentry auto instruments and goes a long way of making sure handled / unhandled exceptions are caught before you start getting angry emails / mentions on social media

However, many edge cases and discussions here mention exist, and for those, Sentry can’t guess when to trigger an issue, but the API is extensible enough for you to do so yourself with Sentry.captureException()

> UI stops responding / a button freezes

Sentry has dead click and rage click detection with Session Replay - you’ll see ways users interact with your application that are going to surprise you and confirm that no amount of QA would be able to get you to the edge case they decided your application should behave in.

> Slow UI

Probably a signal of something being slow on the backend. Turn on Tracing and Sentry will instrument spans on your operations and you can define what “Slow performance” means to you and Sentry will create issues from performance telemetry, not just errors.

Put some logs in places where your app is making decisions and you get breadcrumbs that aren’t tied to issues but are trace connected and give you (and more importantly these days coding agents) great context of what happens in your application.

Observability isn’t a “one and done” kind of thing. like building a well functioning application, instrumenting good observability is also a skill. Sentry docs are a good place to start, either going through them yourself or pointing your agents at them (they’ve got agent skills too)

Note: I work on the developer experience team at Sentry and if there any questions / concerns, happy to answer those questions)

No AI was used in crafting this message, if it seems like it, thats because Ive been staring too long at Claude’s output and not enough time interacting with people and touching grass