Interactive Sentry Demo
Sentry is an error tracking and performance monitoring tool for developers. It captures exceptions and slow transactions in production, groups them into issues with full stack traces and context, and alerts the team so bugs get found before users report them.
What is Sentry?
Sentry is application monitoring built around errors. You add its SDK to your codebase, and when something throws an exception or a request runs slowly in production, Sentry captures it with the full stack trace, the variables in scope, the browser or server environment, and the sequence of events that led up to it. Instead of a vague bug report from a user, you get the exact line of code and the conditions that broke it.
The part that makes Sentry usable at scale is how it groups errors. Rather than flooding you with one alert per occurrence, it fingerprints similar errors into a single issue and tracks how often it happens, how many users it affects, and which release introduced it. That last point matters: Sentry ties errors to deploys, so you can see that a spike started with a specific version and roll back or fix with confidence about the cause.
Sentry has expanded beyond errors into performance monitoring and session replay, which records what a user did in the browser before hitting a problem. It supports most major languages and frameworks. It started as an open-source project and still offers self-hosting, alongside a cloud product priced by the volume of events, errors, and replays you send.
How to get started with Sentry
- 1
Create a project and install the SDK
Set up a Sentry project for your application, which gives you a DSN key that identifies where events should go. Install the SDK for your language or framework and initialize it with that key. Sentry's setup guides include the exact snippet for most stacks, so this step is usually a few lines of code.
- 2
Trigger a test error
Throw a deliberate test error to confirm events are flowing. It appears in your Sentry dashboard within seconds, complete with a stack trace. Seeing that first event arrive verifies the integration before you depend on it for real problems in production.
- 3
Connect releases and source maps
Configure Sentry to tag events with your release version and, for frontend apps, upload source maps so minified stack traces map back to readable code. This is what lets Sentry tell you which deploy introduced an error, which is one of its most useful features once you ship regularly.
- 4
Set up alert rules
Define when Sentry should notify you and where, whether that is Slack, email, or PagerDuty. Sensible rules might alert on a new issue in the latest release or on an error rate crossing a threshold. Spend time here, because good alert rules are the difference between Sentry being useful and being noise.
- 5
Triage issues and assign owners
As real issues come in, use the dashboard to assign them, mark them resolved, and watch for regressions if a resolved issue reappears in a later release. Building a habit of triaging the issue stream keeps it as a trusted signal rather than a backlog everyone learns to ignore.
Who is Sentry most useful for?
Sentry is most useful for engineering teams running software in production who need to know about problems before customers tell them. A backend team gets alerted the moment an exception rate climbs, a frontend team sees the JavaScript errors real users hit across different browsers, and on-call engineers get the context to diagnose an incident without trying to reproduce it blind. The shift is from reactive bug reports to proactive detection.
It fits teams of almost any size, from a solo developer who wants visibility into a side project to a large org with strict reliability targets. The release tracking is especially valuable for teams that deploy often, because it answers the question of which change caused a regression. For support and product teams, the user-impact data turns a bug into a prioritization decision rather than a guess.
Sentry is less relevant for fully static sites with no application logic, or for teams that have standardized on a broad observability suite that already covers error tracking. There is also tuning involved: without sensible alert rules and sampling, a busy app can generate enough noise that the signal gets lost. Set up well, though, it becomes the first place engineers look when something breaks.
Error and application monitoring tools differ in whether they lead with backend errors, frontend sessions, or full-stack observability, so the right pick depends on where your problems tend to surface.
LogRocket leads with session replay, recording exactly what a user did in the browser before an issue, and combines it with frontend performance and error data. It answers the question of what the user experienced more directly than Sentry does. Teams focused on frontend and product issues often prefer it, and some run it alongside Sentry's backend error tracking.
View demo →
Datadog spans infrastructure metrics, logs, traces, and application monitoring in one broad platform. It suits larger organizations that want a single pane of glass across their whole system rather than a focused error tool. That breadth comes with more cost and complexity, so teams that only need error tracking often find Sentry more direct.
Rollbar is a close competitor on the core job of capturing and grouping errors, with an emphasis on automating how issues are triaged and assigned. It covers similar languages and frameworks to Sentry. The choice between them often comes down to the specifics of grouping behavior, workflow, and pricing rather than a fundamental difference in approach.
Bugsnag centers on application stability and gives teams a stability score to decide whether a release is healthy enough to keep rolling out. It is strong on mobile error monitoring in particular. Teams that frame reliability around release health and mobile apps gravitate to it, while Sentry casts a wider net across web and backend stacks.
FAQs on Sentry
Commonly asked questions about Sentry. Have more? Reach out and our team will be happy to help.
What does Sentry actually capture when an error happens?
When an error occurs, Sentry captures the full stack trace down to the line of code, the values of variables in scope, the environment such as browser or server and OS, and a breadcrumb trail of the events leading up to it. The goal is that you can diagnose the problem from the issue itself, without needing to reproduce it. It also records which release the error came from.
How does Sentry avoid flooding us with alerts?
Sentry groups similar errors into a single issue by fingerprinting them, so a bug that happens ten thousand times is one issue, not ten thousand alerts. From there you set alert rules based on conditions like frequency, number of users affected, or whether an issue is new in the latest release. Tuning those rules is what keeps Sentry useful rather than noisy on a busy application.
How does Sentry compare to LogRocket?
Sentry and LogRocket overlap but lead with different strengths. Sentry is error-first: its core is capturing exceptions and performance issues across the whole stack, backend and frontend. LogRocket leads with session replay and frontend analytics, showing you exactly what the user did. Many teams use Sentry for backend and error monitoring and reach for LogRocket when they want to watch the full user session, and the two are sometimes run together.
Does Sentry do more than error tracking now?
Sentry has grown beyond errors into performance monitoring, which surfaces slow transactions and database queries, and session replay, which records the user's browser session leading up to an issue. The error tracking is still the core, but these additions let a team move from knowing that something is slow or broken to seeing why, without leaving the tool.
Can I self-host Sentry?
Sentry began as an open-source project and you can self-host it, which appeals to teams with data residency or compliance requirements that rule out sending error data to a third party. The cloud product is what most teams use, priced by the volume of events and replays you send. Self-hosting trades that convenience for control, along with the operational work of running it yourself.