Open source alternatives to Sentry

What Sentry does

Sentry started as an error tracker and has grown into an application monitoring suite. Errors are grouped into issues with stack traces, context and release information, and the same SDKs can send traces and spans, logs, session replays, profiles and user feedback. Cron and uptime monitors, dashboards, release tracking and AI features under the Seer name sit on top. SDKs are available for most languages and frameworks, from browser JavaScript to mobile and backend platforms.

It is offered as a hosted service at sentry.io and as a self-hosted distribution. Sentry’s code is published under the Functional Source License: each version becomes Apache-2.0 two years after release, but until then it may not be used to offer a competing service. That makes it source-available rather than open source.

Why people look for an alternative

• Billing by volume. Paid plans include reserved monthly volumes for each data type (errors, spans, replays, logs and more), with a pay-as-you-go budget on top. Sentry’s documentation says data sent after both are used up is dropped, so a spike late in the month can leave you without error data until the next cycle.
• Free plan limits. The free Developer plan is for one user and keeps a 30-day lookback, which rules it out for most teams.
• Data location. Organizations choose US or EU storage when they are created, and the documentation says an existing organization cannot be moved; you would have to start a new one.
• Heavy self-hosting. Self-hosted Sentry needs at least 4 CPU cores and 16 GB of RAM plus 16 GB of swap, with 32 GB recommended, and runs Kafka, ClickHouse, Redis, PostgreSQL and several Sentry services. Sentry describes it as a minimal setup for simple use cases, supported mainly by the community.
• License. Teams that require OSI-approved licenses cannot treat the Functional Source License as open source.

What to compare in an alternative

1. SDK compatibility. A server that accepts Sentry SDK events lets you switch by changing the DSN; anything else means replacing client code across your applications.
2. The Sentry features you use. Errors and alerts are covered widely; tracing, logs and release health less so; session replay and profiling are rarer.
3. Self-hosting footprint. The services and memory a tool needs, and how upgrades work.
4. Retention and quotas. On your own server, retention is limited by your disk and settings rather than a plan.
5. Hosted option. Whether the developers also run a hosted service if you do not want to operate it.

Which one to choose

Rustrak is the closest replacement for teams that already use Sentry SDKs: it implements Sentry’s ingestion protocol, so apps switch by changing their DSN, and it also takes transactions, logs and release health. It runs as a single process on SQLite, with PostgreSQL for larger volumes, but it is young, self-hosted only and has no session replay or profiling.

Exceptionless is a mature alternative for .NET and JavaScript applications, with errors, logs and feature usage in one place, a hosted service and a self-hosted option on Elasticsearch. It uses its own client libraries, so switching means replacing the Sentry SDK.

For narrower needs, Measure covers mobile crash reporting with replay and performance data, and Rails or Phoenix teams can keep errors inside the application with Solid Errors or ErrorTracker. The error tracking guide compares all of them.