Sentry vs. Bugsink

If you’re running software in production, you should probably have an Error Tracker in place. If you’re reading this, you’re likely trying to choose between Bugsink and Sentry.

Both provide a place for your errors to be sent to, group them into issues, alert you when something goes wrong, and give you the context you need to debug.

But they’re quite different products. Sentry has grown into a broad observability platform. Bugsink sticks to Error Tracking.

You’re reading this on the Bugsink website and I built Bugsink, so this comparison obviously comes with a bias. I used Sentry for years, though, and my experience self-hosting it is part of why Bugsink exists.

People rarely change error trackers for the fun of it. A growing bill, the work of running Sentry’s self-hosted stack, or a requirement for a European supplier can make the change worth considering. The same Sentry SDKs make switching practical; they do not start the search. Sentry’s broader feature set is also a good reason to stay.

What an error looks like

The main reason to have an Error Tracker is to have a place where you can actually look at errors. Here’s what the same error looks like in Bugsink and Sentry:

Bugsink

Bugsink puts the stacktrace first. The complete exception chain is visible in one pass, source context is open, and local variables are beside the relevant frame.

Request data, tags, user information, runtime details, and release and environment information remain available in a separate details view. Tag distributions show whether an issue only affects one browser, release, tenant, or server. A 28-day occurrence sparkline shows when it started and whether it has subsided.

Sentry

Sentry connects the error to much more: traces, replays, releases, suspect commits, ownership, and the wider health of the application. That is valuable when you use those systems together. It also produces a busier page, with workflow controls, AI features, graphs, tabs, and metadata competing with the stacktrace.

Alerting

For alerts, Bugsink follows the issue lifecycle: a new issue, a regression, or an issue crossing its mute threshold. Email preferences can be set at global, team, and project level. Project alerts can also go straight to Slack, Mattermost, Discord, Microsoft Teams, Telegram, Google Chat, or a custom JSON webhook. These integrations are included on the free plan; the alerting guide has the details.

Sentry goes much further into ownership, escalation, metric alerts, anomaly detection, and third-party workflow integrations. Also: the free plan does not include webhooks, so you have to pay to get alerts into Slack, Teams, or Discord.

Search

Bugsink search handles free text and structured key:value terms across issues and events. That includes exception type, message, environment, release, arbitrary tags, and request URLs. The syntax is deliberately small and is documented with examples.

Sentry has the deeper search and reporting model. It is especially strong when queries cross errors, traces, releases, and other Sentry data. Naturally, that also gives it the larger query language to learn.

APM and observability

Sentry is much more than an error tracker: tracing, replay, logs, profiling, application metrics, dashboards, uptime and cron monitoring, release health, and Seer. Its cross-linking between those features is a genuine advantage.

Bugsink is an Error Tracker, not an APM. It does not collect traces, replays, performance transactions, or uptime checks.

SDKs and source maps

Both products use the Sentry SDKs. For a new application, install the SDK for your language or framework and give it a DSN.

If you already use Sentry, testing Bugsink can be just a DSN change. There are no Bugsink-specific forks or wrappers to adopt. Historical events stay where they are; new events go to Bugsink as soon as the application uses its Bugsink DSN.

Bugsink supports debug-ID source-map uploads through sentry-cli.

Pricing

Bugsink is cheaper at every paid level shown below. The Bugsink price includes an instance we run for you: we provision it and handle TLS certificates, upgrades, storage, backups, and outgoing email. The managed page has the details.

Sentry does more, of course, but these prices are only for error tracking. Using Sentry’s other products costs more.

Published monthly prices in US dollars, September 2026:

The Sentry estimates use its $26 annual-billing Team base, including 50K errors, followed by its published pay-as-you-go error rates. Monthly billing costs more. The Bugsink figures use our regular monthly prices. Bugsink only meters errors; Sentry meters its different products separately.

The pricing article shows the same calculation at larger volumes.

European data sovereignty

For European customers, application data in the EU can be a preference or a hard requirement. So can buying from a European supplier. Those are two different requirements.

Bugsink B.V. is a Dutch company. When we run Bugsink for you, our DPA states that we store and process all personal data in the Bugsink service in the EU. The application infrastructure and outgoing email are European too.

Sentry offers an EU data region, but Sentry remains an American supplier. The longer European Sentry alternative explains why that distinction can matter.

Self-hosting

The two self-hosted versions have very different requirements.

Bugsink Self-Hosted

Self-Hosted Bugsink is one application. It can run as one container with SQLite, or use PostgreSQL/MySQL when that better fits your setup. There is no Redis service or separate queue to operate. The installation page and upgrade guide cover the short setup and update paths.

In our benchmark, a 2-vCPU, 4GB, €5/month VPS sustained 1.5 million events per day. Smart retention keeps complete events at normal volume and representative samples when traffic spikes, while preserving grouping and issue counts.

Sentry Self-Hosted

Full self-hosted Sentry is a distributed stack involving PostgreSQL, Kafka, Redis, ClickHouse, Snuba, Symbolicator, Relay, and more. Its published minimum is 4 CPU cores, 16GB RAM plus 16GB swap, and 20GB of disk; Sentry recommends 32GB RAM. Sentry describes the self-hosted distribution as intended for “low-volume deployments and proofs-of-concept”, and offers no general guidance for scaling it up.

Sentry also offers an Errors Only profile with Issues, Alerts, Integrations, and Dashboards. The documentation says that profile emphasizes minimizing system resources, but publishes no separate hardware requirements for it.

License

Both products are source-available rather than OSI Open Source. Bugsink uses the Polyform Shield License; Sentry uses the Functional Source License. Both permit self-hosting and restrict using the software to provide a competing service. Sentry’s licence converts to Apache 2.0 after two years.

Which one would I choose?

Choose Sentry if you want the full observability package and will use the connections between errors, traces, replays, profiling, logs, releases, and AI features.

Choose Bugsink when the job is Error Tracking. It gives the error the clearest place in the UI, costs less as event volume grows, and is supplied by a European company. If you Self-Host, it remains a small application rather than an infrastructure project.

Stop reading and Sign up for free; you’ll know more in one minute and a DSN-change than all the reading in the world