- More than error tracking
- Three words you'll see everywhere
- Switching performance monitoring on
- What the dashboards cover
- Problems it spots for you
- Who should own the setup
- Nothing shows until you set a sample rate
- Datadog and New Relic as alternatives
- My verdict for teams already on Sentry
- Frequently asked questions
Yes. Sentry tracks application performance through tracing, measuring throughput and latency and showing how errors affect your services. You switch it on by enabling tracing in your SDK. Sentry then auto-instruments common operations in most frameworks and fills pre-built dashboards for frontend, backend, mobile and AI.
More than error tracking
Plenty of teams know Sentry as the tool that emails them when something crashes. But it's also got distributed tracing, automated issue detection and pre-built dashboards to track performance across your whole stack. With tracing on, it measures throughput and latency and shows the impact of errors across services.
Three words you'll see everywhere
| Term | What it means |
|---|---|
| Trace | A record of connected events and operations, identified by a trace ID passed between frontend and backend services |
| Span | A named, timed operation within a trace |
| Transaction | A legacy concept, now replaced by service spans |
That last row's important if you're reading older tutorials. New SDKs and features use spans exclusively, so guides that talk about transactions are describing the old model.
Switching performance monitoring on
- Add Sentry to your app with the SDK for your framework.
- Enable tracing by setting a trace sample rate. In the JavaScript SDK that's tracesSampleRate.
- If you've got a frontend and a backend, instrument both and set tracePropagationTargets, which controls the URLs trace propagation is enabled for.
- Open the performance and insights dashboards once traces start arriving.
- Review the detected performance issues and drill from a slow span into its trace.
For most frameworks, including Next.js, Laravel, Rails, Django and Express, Sentry auto-instruments common operations such as HTTP requests, database queries and template rendering. You don't have to wrap every function by hand; custom spans are there when you want more detail.
What the dashboards cover
| Layer | What you'll see |
|---|---|
| Frontend | Core Web Vitals and duration |
| Backend | Database queries, API calls, caches, queues and crons |
| Mobile | App starts and screen loads |
| AI | LLM call latency and token usage |
The pre-built dashboards can't be edited, but you can duplicate one into a custom dashboard and change that. Queries can slice span data by any attribute, so you can find the p95 duration of a single endpoint or compare a time window against a baseline after a release.
Problems it spots for you
Sentry automatically detects common performance problems. Examples include consecutive database queries or HTTP requests that could have been batched, and database or file I/O happening on the main thread. Every trace connects to logs, session replays and profiles, so you can go from a slow span straight to the functions using CPU time. For a small development team, that saves a lot of guesswork when a page is slow.
Who should own the setup
It's a developer job, but it's a short one, and the decisions are business decisions. Agree which pages or endpoints matter most, such as checkout, sign-up or your booking form, and ask your developer to make sure those are traced end to end, frontend and backend. Then agree who looks at the detected issues each week. A dashboard nobody opens won't make anything faster.
Nothing shows until you set a sample rate
Sentry Docs, in the tracing guide, make the point that trips people up. Performance data doesn't appear by default. You've got to turn tracing on and choose a sampling rate, and Sentry itself advises revisiting that rate in production, or using tracesSampler for finer control. If your performance dashboards are empty, the sample rate is the first place to look.
If you're comparing monitoring for other parts of your stack, see my roundups of database monitoring tools and API monitoring tools.
Datadog and New Relic as alternatives
Datadog Application Performance Monitoring provides distributed tracing, out-of-the-box dashboards and correlation with other telemetry, and can be started with Single Step Instrumentation.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
New Relic APM provides detailed transaction traces that show exactly where slowdowns occur.
My verdict for teams already on Sentry
If you already use Sentry for errors, switch on tracing before you look at another tool. Set a sample rate, instrument the frontend and backend together, and let the auto-detection point you at the slow queries. Revisit the rate once you see how much data comes in.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Does Sentry do more than error tracking?
Yes. It offers tracing, performance dashboards and automated detection of performance issues alongside error monitoring.
Does my code need instrumenting by hand?
For most frameworks it auto-instruments common operations once tracing is enabled. Custom spans are optional.
What does a trace show?
The timing and flow of a request through your application, from frontend to backend, as connected spans under one trace ID.
Can I see performance for mobile apps and AI calls?
Yes. There are dashboards for mobile (app starts, screen loads) and AI (LLM call latency, token usage).
What are transactions in Sentry?
A legacy concept now replaced by service spans.
