Sentry vs Logging
Every signal, one platform
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. Instead of one firehose of logs, Sentry collects several purpose-built signals (errors, spans, application metrics, and logs) and layers workflows on top that intelligently group errors, trace performance, and surface the most critical issues, 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
Spans & Traces
Application Metrics
Logs
Session Replay
Alerts & Dashboards
Seer (AI)
AI Agent Tools
Logging = everything, everywhere.
Sentry takes a different tack. Instead of shoving every byte into one endless log stream, we break telemetry into four primary debugging signals: errors, spans, application metrics, and logs. Then workflows like alerts, replays, Seer, and agent tooling sit on top.
When do I use each?
When to use Errors
- Track and automatically group similar failures into Issues
- Get stack traces with full context for every crash
- Automatic alerts when new or escalating issues appear
- Seer AI analyzes root causes and suggests fixes
- View Errors docs →
When to use Spans
- Identify performance bottlenecks in multi-service requests
- See exactly which DB query or API call is slow
- Trace how a slow SQL query or downstream API cascades into a slow request
- Auto-create Issues when latency exceeds thresholds
- View Spans docs →
When to use Application Metrics
- Track known health and behavior signals in your app with counters, gauges, and distributions
- Ask questions about users and cohorts to understand impact (e.g. a single job causing queue backlog)
- Answer complex questions at query time with flexible aggregations, equations, and grouping
- Trace a spike in a well-known KPI back to related traces, logs, and errors to find root cause
- View Application Metrics docs →
When to use Logs
- Add structured context to debugging (user IDs, order refs, config)
- Lightweight monitoring without significant overhead
- Audit user actions, navigation, and configuration changes
- Correlate log entries with traces and errors automatically
- View Logs docs →
Quick decision guide
| What you want to know | Use |
|---|---|
| Did this handler run, and with which user ID and payload? | 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 |
| How many checkouts failed this hour? | Application Metrics |
| What is the current queue depth and why did it spike? | Application Metrics (gauge) + Traces |
| 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 |
| Track email.sent count per tenant and provider. | Application Metrics (attributes) |
| What's the root cause of this error and how do I fix it? | Seer (AI) |
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 give you request-level context: what happened, where it slowed down, and which records or users were involved. Discover our structured, searchable approach to Sentry Logs.
Application Metrics are best for application and code-based health signals: numeric indicators that tell you whether your application logic is behaving as expected. They give you aggregate visibility with counters, gauges, and distributions, and they are the right tool for rates, volumes, success and failure counts, queue depth, and similar questions over time.
What makes Application Metrics different is that they are trace-connected. Start in the Aggregates view to spot the trend, switch to Samples to inspect individual metric events, then open the related trace, spans, logs, and errors that explain why the metric moved.
Each metric event can carry a unit and custom attributes for grouping and filtering, and Sentry automatically links metrics to the active trace and span when available. That's why Application Metrics fit business KPIs, application health, resource utilization, user action counts, and success or failure rates, but not log aggregation or full request tracing.
Seer, Sentry's AI, works across all of these signals. It can analyze an Issue, identify the root cause, suggest a fix, and even open a pull request so you spend less time in triage and more time shipping.
How it works together
Let's see how these 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, the context around the failure, and the quantitative application health signal that told you something changed.