Sentry captures errors from running software and gives you enough context to fix them without reproducing the bug. When an exception is thrown, the SDK collects the stack trace, the breadcrumb trail of what happened before it, the release version, the environment, the browser or runtime, and, if you have configured it, the user affected. Identical errors are grouped into a single issue with a count and a timeline, so a thousand occurrences of one fault do not become a thousand notifications.
The part that earns its keep is source map and release handling. Minified production JavaScript produces stack traces that point at column 41,832 of a bundle, which tells you nothing. Upload source maps as part of your build and Sentry shows the original file, the original line and the surrounding code. Connect your repository and it will suggest the commit that introduced the regression and the person who wrote it, which sounds accusatory but in practice just routes the issue to whoever has the most context.
Beyond errors, Sentry does performance monitoring and session replay. Tracing follows a request across services and shows where the time went, including slow database queries and waterfalls of blocking requests. Session replay records a reconstruction of what the user actually did before the error, which resolves the recurring argument about whether a bug is real. Cron monitoring watches scheduled jobs and alerts when one fails to check in. All of it is sampled, and the sample rate is the main lever you have on cost.
The SDKs cover most languages and frameworks: JavaScript and the major frontend frameworks, Python, Ruby, PHP, Go, Java, .NET, Rust, iOS, Android, React Native and Unity. Installation is usually a package and a few lines in your entry point. Getting value out of it takes a little more: unfiltered, Sentry will report every browser extension error and third-party script failure your users encounter, and the first week is largely spent writing ignore rules so the signal is visible.
Sentry is open source and self-hostable, which matters for teams who cannot send stack traces containing user data to a third party, though running it yourself means operating Postgres, Redis, Kafka and ClickHouse. Most teams take the hosted version. Pricing is by event volume across errors, traces and replays, and it becomes the dominant cost consideration on a high-traffic application, which is what the sampling controls are for.
Who it suits: any team running software in production that currently learns about failures from customer emails. Who should be careful: very high volume applications where event pricing needs modelling before adoption.
