What is a good open source alternative to Sentry for error tracking?
The closest open source options are GlitchTip, which is open source and accepts events from Sentry's SDKs, and Sentry's own self-hosted release, which is source-available rather than classic open source and is packaged for low-volume use. Either way you run ingestion, storage, upgrades and backups yourself. Because the SDK protocol is shared, moving between trackers is mostly a DSN change.
Why it happens
People ask for an open source alternative for a few distinct reasons, and the right answer depends on which one is yours. Some want to keep error data, which can contain user identifiers and request payloads, on their own infrastructure for compliance or data residency. Some want to avoid a vendor bill that grows with traffic. Some simply prefer software whose code they can read. These are three different requirements, and a tool can satisfy one without the others.
The reason a drop-in choice exists at all is that the Sentry client SDKs speak an open event protocol. Any server that implements the ingest side of that protocol can receive events from the same SDKs, so the instrumentation in your code is not what ties you to a particular backend. GlitchTip describes itself as an open source, Sentry API compatible error tracking platform that works with Sentry client SDKs and is easier to run (GlitchTip homepage, read 2026-11-13).
The licensing detail matters. Sentry's self-hosted repository is described by its own README as feature-complete and packaged for low-volume deployments and proofs-of-concept, and the repository is tagged fair-source (GitHub, read 2026-11-13). Fair-source means you can read and run the code, but it is not a classic open source license, so check that the terms fit how you intend to use it. Running either option also moves the operational work onto you: receiving events, storing them, upgrading and backing up.
How to pick and run an open source error tracker
Write down why you want open source
Separate the three motives: data must stay in your network, the cost should not scale with traffic, or you want readable code. If the real driver is data residency or a compliance rule, you need self-hosting specifically, and a hosted tool in your region may or may not satisfy the rule. If the driver is cost, include the engineer time to run the server before you compare anything.
Shortlist by criteria, not by name
Use the table below. The two cases that matter most are how heavy the deployment is and how much of the Sentry feature set you actually use. A lighter server is easier to keep running but may not implement every feature your SDKs can send, so check the ones you rely on, such as source maps, release tracking and performance data, before committing.
Stand it up on a throwaway machine first
Install your shortlisted tool on a small test host or a local container setup following its own documentation. Do not point production at it yet. The goal is to learn how many moving parts it has, how much memory and disk it uses while idle, and how you would back it up, because those answers decide whether you can keep it healthy.
Send a real error from your own SDK
Create a project in the new server, copy its DSN and set it in a non-production environment of your app. Throw a deliberate error and confirm that it arrives with the stack trace, the release and the breadcrumbs intact. Because the SDK protocol is shared, this is normally a one-line change of the DSN value and nothing else in your code.
// before Sentry.init({ dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>" }); // after: same SDK, your own server Sentry.init({ dsn: "https://<key>@errors.example.internal/<projectId>" });Schedule upgrades, backups and capacity before going live
Decide who applies upgrades, how often, and how you restore from backup, and test a restore once. Set retention so storage does not grow without limit, and put an alert on the server itself so that you learn about an outage of the tracker from something other than the tracker. An error tracker that is down reports nothing, silently.
Cut over gradually and keep a rollback
Move one low-risk service first, watch it for a few days and keep the old DSN in your configuration so that you can switch back by changing one value. Move the remaining services once ingestion volume, disk growth and alert delivery look stable.
| Criterion | Self-hosted (GlitchTip or Sentry self-hosted) | Hosted service |
|---|---|---|
| Who runs ingestion and storage | You do | The vendor does |
| Upgrades and security patches | Your team applies them on your schedule | Applied by the vendor |
| Backups and restore | You design, test and pay for them | Vendor responsibility; check what they state |
| Data location | Entirely under your control | Depends on the vendor's regions and terms |
| Source code access | Yes, under the project's license (check the license terms) | Usually closed |
| Outage of the tracker | Your on-call handles it | Vendor status page and support |
| Moving off later | SDKs stay the same; change the DSN | SDKs stay the same; change the DSN |
Criteria compiled from the Sentry self-hosted README (github.com/getsentry/self-hosted) and the GlitchTip homepage (glitchtip.com), both read 2026-11-13. No vendor prices are compared.
When to use Bugsly
Bugsly is not open source and cannot be self-hosted. It is a hosted, closed-source service. What it shares with the options above is the ingest side: it accepts Sentry's event protocol, so you keep your Sentry SDK and change the DSN to https://<public_key>@bugsly.dev/<project_id>. That makes it a reasonable hosted option if what you actually wanted was to stop operating a server, rather than to hold the code yourself.
If you take that route, the limits are concrete: no SSO, no Jira, Linear or PagerDuty actions, no native minidump ingestion, and history from another tool cannot be imported, so a new project starts fresh. Alerts go to email, Slack, Telegram or a webhook. For cost, see /pricing, where the billing meter is described.
When Bugsly is not the right answer
If your requirement is that the data never leaves your infrastructure, or that you can read and modify the server's source, Bugsly is not the answer. Choose GlitchTip or Sentry's self-hosted release, and budget the operations work described above.
If you need single sign-on or incident-management integrations, pick a tracker that provides them, hosted or self-hosted. Review the license of any fair-source project before building a product on top of it.
Ask your AI assistant to do it
With the Bugsly MCP server connected (https://bugsly.dev/api/mcp; setup for ChatGPT, Claude, Cursor and Gemini CLI is on /mcp), paste this. The assistant reads first and reports back; you decide what happens next.
Assign to Bugsly: use list_projects to show my projects, then list_issues for the one I name, and tell me which errors would still need attention after a move, based on whether they are unresolved. Do not resolve or ignore anything; show me what you found so I can approve the next step.
Frequently asked questions
Is Sentry open source?
Its self-hosted repository is tagged fair-source, which means the code is source-available but not a classic open source license. Read the license terms before relying on it, particularly for commercial use.
Can GlitchTip receive events from the Sentry SDKs?
Yes. GlitchTip states that it is compatible with Sentry client SDKs, so you normally keep your instrumentation and change the DSN. Check that the specific SDK features you use, such as source maps, are supported.
Is self-hosting an error tracker cheaper?
Not automatically. You avoid a vendor bill but take on servers, storage, upgrades, backups and on-call time. It pays off mainly when data residency, compliance or very high volume is the reason you are doing it.
Can I try a tracker without changing my code?
Yes, because the SDK protocol is shared. A new DSN in a non-production environment is enough to test whether a server receives and displays your errors correctly.
Sources
- Sentry self-hosted README (read 2026-11-13)
- GlitchTip homepage (read 2026-11-13)
Related
- GlitchTip vs Bugsly
- Best open source error tracking
- Sentry alternative comparison
- Migrate from Sentry
- All problems and solutions
Sentry is a trademark of its owner; Bugsly is not affiliated with or endorsed by Sentry. “Sentry-compatible” only means Bugsly accepts events sent by Sentry's open SDKs.