Best European Alternatives to Sentry

Why people leave Sentry

Sentry is very good at the thing it does. It groups an exception into an issue, tells you which release broke it and how many people hit it, and it does that better than anything that costs less. Teams do not leave because the stack traces are wrong.

They leave when they discover that the European version of Sentry is a different account rather than a setting. Storage in Frankfurt exists, at de.sentry.io, alongside the American region in Iowa.

The location is fixed when the organisation is created, and Sentry's own documentation says an existing SaaS organisation cannot be switched — the route is to create a new one. If you are already on us.sentry.io and someone in legal has now asked the question, you are starting a fresh organisation either way, and that is the cheapest moment you will ever get to weigh the vendor.

The second trigger is the escape hatch turning out to be narrower than remembered. "It is open source, we can host it ourselves" was true in 2018. Since 17 November 2023 the code has been under the Functional Source License, which replaced the Business Source License and only becomes Apache 2.0 or MIT two years after each release.

• The region is a decision you already made Both regions are real: the US region runs from Iowa, the EU region from Frankfurt, and you pick one when the organisation is created. What you cannot do is change your mind. The documentation is unambiguous that a SaaS organisation's storage location cannot be changed and that creating a new organisation is the only way to switch. A setting you can only set once is not a setting; it is a migration, and a migration is a competitive moment.
• Open source with a two-year delay The Functional Source License lets you read the code, run it internally and modify it, and forbids using it in a product that competes with Sentry. Two years after a release, that release converts to Apache 2.0 or MIT. That is a more generous arrangement than most source-available licences and it is still not an OSI licence on the day you download it. If your procurement rule says "open source", the honest answer about current Sentry is no, with a date attached.
• The self-hosted build is a blueprint Sentry publishes what you need to run it: four CPU cores, 16 GB of RAM plus 16 GB of swap, 32 GB recommended, and a warning that disk I/O decides whether it holds up. The documentation describes the result as coming with no guarantees or dedicated support, points you at a community Discord, and stops where clustering begins — at which point it suggests the hosted product. Teams that adopted Sentry because they could keep it in-house tend to find that out on the day the single node stops coping.
• The meter counts events, not people This is where most comparison pages get Sentry wrong. There is no per-seat fee above the free plan: Team is $26 a month billed annually with unlimited users and 50,000 errors, Business $80. The bill grows with errors, spans, replays and logs, so a European alternative only saves money if it charges less per event or lets the events land on your own disk. Cutting cost on Sentry means sampling your own telemetry, which is the one thing you bought it to avoid.

What you have to replace, not just match

Work out which of the three things Sentry does for you is the one you would actually miss, because the tools below answer them separately.

The first is the error pipeline: an SDK in every service, events grouped into issues, fingerprinting, release tagging and a workflow for assigning and resolving. The second is everything Sentry built around that core over the last five years — session replay, profiling, span-level performance, logs. The third is the SDK estate itself, which is the part nobody counts: the dozens of services already sending to a Sentry DSN.

GlitchTip is the only option here that leaves the third untouched, because it speaks the same protocol. Uptrace and Elastic APM both mean instrumenting again, which is a legitimate choice if you were going to standardise on OpenTelemetry anyway and a poor one if error tracking is all you wanted.

The alternatives compared

How each alternative compares to Sentry

What actually breaks when you switch

The DSN estate is the first surprise. Sentry ends up configured in application code, in container environment variables, in CI pipelines, in mobile builds released months ago and in a Lambda nobody has opened since. GlitchTip absorbs all of them with one value changed; the other two mean finding every one of those places and replacing the SDK inside it. Make the list before choosing, because the length of that list is most of the decision.

The second is that history does not travel. No route exists for moving grouped issues, their comments and their resolution states to another vendor, and even Sentry's own relocation tooling for self-hosted installs leaves events, transactions, profiles and logs behind. Run both systems for a fortnight, let the open issues resolve themselves, and treat the old account as an archive you can read until the plan lapses.

The third is quota shape. Sentry sells you errors, spans, replays and logs as separate allowances, so your team has learned to reason about the bill in those terms. Uptrace charges by ingested gigabyte, GlitchTip by event, and a self-managed Elastic cluster by hardware. Somebody has to re-derive what "too noisy" means in the new unit, and until they do, the first invoice will be a surprise in one direction or the other.

Can I move my existing Sentry organisation to the EU region?

No. Sentry offers storage in Frankfurt and in Iowa, and the choice is made when the organisation is created. For a SaaS customer the documentation states plainly that the storage location cannot be changed afterwards and that the only way to switch is to create a new organisation.

That matters more than it sounds. A new organisation means new projects, new DSNs deployed to every service, new integrations, new alert rules and no history carried across. Self-hosted installs can relocate accounts, settings, projects, teams, dashboards and alert rules — but not the events, transactions, profiles or logs, which is to say not the data anyone wanted to keep.

So the work of getting Sentry into Europe is roughly the work of adopting a different error tracker. Do that arithmetic before you assume staying is the conservative option.

Is Sentry open source, and does it matter?

Sentry is source-available under the Functional Source License, adopted on 17 November 2023 to replace the Business Source License. You may read it, run it internally, modify it and contribute back. You may not build a competing commercial service on it until the release is two years old, at which point it becomes Apache 2.0 or MIT.

For a company that simply wants to run its own error tracking, this changes almost nothing in practice. For a public body or a procurement process with an open-source requirement written into it, it changes everything, because on the day you take the code it is not an OSI-approved licence.

The comparison that makes the difference visible: Uptrace is AGPL-3.0 today, with no waiting period and no competing-use clause. If the licence is why you are on this page, that is the row to look at.

How much work is repointing to GlitchTip?

Less than any other move on this page, because GlitchTip implements Sentry's ingest protocol. The Sentry SDKs already in your services keep working; you change the DSN they point at and events start arriving somewhere else. For a team with twenty services and a shared configuration, that is an afternoon and a deploy.

What does not come with you is the history. Existing issues, their comments, their resolution state and the events behind them stay in Sentry until the account lapses. The usual approach is to run both for a fortnight, let the old issues close naturally, and export nothing.

And you will notice the ceiling. Session replay is absent, profiling is absent, and performance monitoring is present but thinner than what Sentry has built since 2021. If your team lives in replays, this is not the swap for you.

What do I give up by leaving Sentry's SDKs behind?

Sentry's agents do more than post a stack trace. Breadcrumbs, release health, user context and source-map handling are the reason an unminified frontend error is readable at all, and they are Sentry's own work rather than a standard anybody else implements.

OpenTelemetry, which is what Uptrace and Elastic APM consume, was designed around traces and metrics rather than exceptions. It will tell you which span failed and how often, with far better coverage across services than Sentry gives you. It will not hand you the same grouped, deduplicated, assignable issue with a release attached.

The honest framing is that these are two different products that overlap. Teams that move from Sentry to an OpenTelemetry backend and expect error tracking to survive the trip are usually disappointed in month two.

Which one to pick

If the reason you are reading this is that someone asked where the error data lives and you discovered the region cannot be changed, GlitchTip is the pragmatic answer: the same protocol, a German instance or your own server, and a bill that is smaller per event at every tier.

If the reason is the licence — a procurement rule, a public-sector requirement, or a plain dislike of source-available terms with a two-year fuse — Uptrace is the only entry here that is AGPL today, and OpenTelemetry means the decision after this one is cheaper than this one was.

If you already run Elasticsearch for logs, Elastic APM is the option that makes the investigation better rather than merely relocating it, and it is the only one where the event data need never leave your own hardware.

And if what you actually depend on is session replay, profiling and span-level performance analysis together, none of these three replaces that. The honest move is to create a new organisation in Frankfurt, accept that jurisdiction still follows Functional Software, Inc., and revisit when the feature you cannot live without has an equivalent here.