Sentry vs Logging

Three signals, one solution

Isn't Sentry just logging?

While Sentry and traditional logging tools may seem similar, they both capture information about what's happening in an application, their goals and design philosophies are quite different.

Traditional logging captures everything from apps, infrastructure, and networks. This is great for ops and compliance, but for developers, it means a flood of noisy, low-value logs that slow down debugging.

Sentry finds and fixes bugs fast. Unlike traditional logging, Sentry does the heavy lifting: it intelligently groups errors, traces every performance detail, and brings the most critical issues to the forefront—so you can skip the log fatigue.

What does Sentry do?

By focusing on debugging and remediation rather than just observability, Sentry helps developers move from "What's broken?" to "Here's how to fix it."

Sentry is designed to work across any kind of application: server-side (backend), mobile and desktop apps, and web-based (frontend) clients. The broad support makes it a powerful and integrated tool also for teams maintaining complex, multi-platform systems.

Sentry provides multiple core capabilities that work together to help you debug faster:

Errors & Issues

Captures errors and crashes, then groups them into actionable Issues for fast resolution.

Spans & Traces

Distributed tracing pinpoints slowdowns and shows how your services connect.

Replays

See what users did before errors, making bugs easy to reproduce and fix.

Logs

Structured logs add context to errors and traces—no more endless log searching.

Alerts & Workflows

Custom alerts and workflows keep your team on top of every issue.

AI Assistance

Sentry's AI agent, Seer, finds root causes, suggests fixes, and codes solutions to streamline debugging.

Logging = everything, everywhere.

Sentry takes a different tack. Instead of shoving every byte into one endless log stream, we break telemetry into three independent signals—each purpose-built, each searchable in one place. Here's when to leverage each and how the Sentry API might look:

When do I use each?

When to use Errors

When you want to track and automatically group similar failures
When you need stack traces to debug application failures
When you want automatic alerts for new or escalating issues
Use captureException(err)*Sentry SDKs instrument these out of the box

When to use Spans

When you need to identify performance bottlenecks
When debugging slow requests across multiple services
When you want performance-based monitoring that can open Issues automatically
Use start_span("db.query")

When to use Logs

When you need structured context for debugging (user IDs, order refs, etc.)
When you need lightweight monitoring without overhead
When you need to track user actions, navigation, or configuration changes
Use logger.info("User signup", user_id=123)

Quick decision guide

Decision matrix showing which Sentry feature to use for different debugging scenarios
What you want to know	Use
Did this handler run, and with which user ID?	Logs
Why is signup 3x slower today?	Spans (timing) + Logs (context)
Show the stack trace for this crash and track it as an Issue.	Errors
Group and dedupe similar crashes automatically.	Errors
Page me if 404s spike above 5 per minute.	Logs (Monitor)
Fire an Issue if more than 10 errors in 5 min.	Errors (alert rule)
How many SQL queries did this request make?	Spans
Correlate a payment exception to the user's activity logs.	Errors + Logs

Only Errors are grouped into Issues, because they include stack traces, making them easy to track and resolve as a team. Use Sentry's Alerts and workflow automation to expand this.

Logs and Spans are lightweight and cost-effective. They don't trigger Issues, but you can set up Metric Alerts (some other tools call these Monitors) to notify you when something unusual happens. Discover our structured, searchable approach to Sentry Logs.

How it works together

Let's see how the three signals work together in a real debugging scenario. Below we'll walk through how an issue caused by a slow database query can impact our e-commerce checkout flow. Together, these signals give you the complete picture: what broke, where it was slow, and the context around the failure.

Next steps

Install the Sentry SDK for your language or framework
Try sending an error, span, and log
Explore the Issues feed to see how Sentry automatically groups related errors
Set up an Alert to get notified about new issues
Try Seer, Sentry's AI agent, to analyze issues and get suggested fixes automatically

Try Sentry For Free