Two halves make one whole
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 systems aim to capture and store every event emitted by software systems. They are often used to collect logs from a wide variety of sources, including:
This broad approach is useful for operations, security, and compliance teams who need full visibility across an entire stack. But when it comes to debugging a specific application issue, particularly in complex, distributed environments, these logs can be overwhelming and noisy.
Most of the logs collected at the infrastructure level aren't useful for developers who are trying to understand why their code is failing. Digging through verbose log streams often slows down debugging rather than accelerating it.
Sentry is a platform purpose-built for developers to detect, troubleshoot, and fix problems with their applications, such as bugs and performance problems. Rather than logging everything indiscriminately, Sentry is focused on surfacing the most important issues—exceptions, crashes, and performance bottlenecks—along with the context needed to understand and fix them.
That includes:
Sentry's developer-centric approach enables faster debugging and issue resolution, without needing to sift through endless lines of logs.
Lastly, 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 now supports structured application logs as an optional, contextual signal to enhance debugging workflows. These logs are scoped to the application layer and are specifically useful when debugging application-level issues. They help developers answer questions like:
Unlike traditional logging platforms, Sentry does not aim to be a centralized log aggregator for your infrastructure. Instead, it focuses on application logs that help you fix bugs, not logs from orchestrators, operating systems, or networking.
Logs in Sentry are correlated with traces when present, so they can be used as contextual information for troubleshooting errors too. This gives developers a complete picture of what's going on in the application—all in one place.
It's important to us here at Sentry that we play well with other tools in the ecosystem. We believe Sentry complements rather than replaces logging and observability platforms like the ELK stack or Grafana. Many teams route infrastructure logs to a centralized log management tool while using Sentry to monitor what matters most to developers: errors, performance issues, and now, relevant application logs.
By focusing on debugging and remediation—not just observability—Sentry helps developers move from "What's broken?" to "Here's how to fix it."
Here’s a quick look at how Sentry handles your personal information (PII).
×We collect PII about people browsing our website, users of the Sentry service, prospective customers, and people who otherwise interact with us.
What if my PII is included in data sent to Sentry by a Sentry customer (e.g., someone using Sentry to monitor their app)? In this case you have to contact the Sentry customer (e.g., the maker of the app). We do not control the data that is sent to us through the Sentry service for the purposes of application monitoring.
Am I included?We may disclose your PII to the following type of recipients:
You may have the following rights related to your PII:
If you have any questions or concerns about your privacy at Sentry, please email us at compliance@sentry.io.
If you are a California resident, see our Supplemental notice.