Which fits your Sentry situation: SaaS, self-hosted Sentry or GlitchTip
If your Sentry renewal, event quota or data residency terms are forcing a decision, Sentry SaaS fits when you want the full hosted workflow without running infrastructure, and GlitchTip fits when you need an open-source (MIT) error tracker that your own team operates and that keeps the Sentry client SDKs you already use. Self-hosted Sentry is a third option, but it is source-available under the Functional Source License rather than open source, so it does not solve a licensing concern on its own.
Sentry SaaS suits teams with no operations capacity to run a database, workers and upgrades, and teams that depend on Sentry's deeper workflow features such as issue grouping rules, release health and integrations that GlitchTip does not cover. Check the feature list on the GlitchTip website against the Sentry features your developers use every week before assuming parity. GlitchTip fits when the stack is PostgreSQL-centred, the team can run a Django application with Docker Compose or Helm, and the workload is errors, performance traces, uptime checks and log search. Because the SDKs stay the same, the application code does not change, only the DSN.
The decision turns on four questions: which Sentry features your teams truly depend on, how many events you send per month, whether events and account data must stay in a specific region or under your own control, and who will operate the service after go-live. Ask Sentry for its current plan and quota terms in writing, and size your event volume from the last few months of usage. If the answers point to self-hosting, a fixed-scope implementation with DeployOpen can define the operating model before you commit.
Which option fits each buyer scenario
This table matches common buyer situations to the option that usually fits better, with the reason drawn from the capabilities documented for each. Read each row as a starting point: confirm the specific features your team depends on against current Sentry and GlitchTip documentation before deciding.
| Buyer scenario | Better fit | Reason |
|---|---|---|
| Team depends on Sentry release tracking and suggestion workflows | Sentry SaaS | GlitchTip's documented coverage is error tracking, performance, uptime and log search. Confirm whether release tracking and suggested-fix workflows are covered before moving, since they are not listed among its features. |
| Team leaving on cost grounds with standard exception and performance needs | GlitchTip (self-hosted) | GlitchTip covers exceptions, slow requests, database calls and uptime, and runs on PostgreSQL 14 or later with a small footprint. Cost then shifts to hosting, upgrades and on-call time, which should be compared in a written scope. |
| Regulated organization needing events and account data in its own data center | GlitchTip (self-hosted) | Self-hosting keeps events and account data inside the organization's infrastructure, and GlitchTip documents Docker Compose and Helm deployments. Confirm the data residency terms your auditors expect for the chosen hosting location. |
| Team wanting errors inside a single observability stack | Neither alone, evaluate SigNoz | GlitchTip is focused on errors, performance and uptime. Teams wanting exceptions, traces, logs and metrics in one tool should compare SigNoz, which is OpenTelemetry-native, before choosing. |
| Team already using Sentry SDKs with no plan to change instrumentation | GlitchTip (self-hosted) | GlitchTip states it accepts data from Sentry's open-source SDKs, so applications can keep their client code and point the DSN at a new endpoint. Test event ingestion in a staging project first. |
| Team that relies on Sentry SSO, audit logs or enterprise administration | Sentry SaaS | Confirm each enterprise control you need against GlitchTip's documentation. Where a control is not documented, plan for it to be built or configured in your environment during implementation. |
Why keeping Sentry SDKs makes the switch less risky
GlitchTip states that it is compatible with Sentry client SDKs and can receive error data from applications through Sentry's open-source SDKs. For a team replacing Sentry SaaS, that means the instrumentation already in the code, including the capture calls, breadcrumbs, integrations and initialization in each service, can stay where it is. The change that matters is the DSN in each project's configuration, which points the SDK at a GlitchTip project instead of a Sentry project. Because the SDK code does not change, the review surface shrinks to configuration, and rollback is a DSN change rather than a redeploy of new code. Confirm the exact SDK versions your teams use against GlitchTip's current compatibility statements before you rely on them, since compatibility is a vendor claim you should verify in your own environment.
Before cutover, test what the SDK actually sends. In a staging environment with a GlitchTip project and a test DSN, trigger a handled exception, an unhandled exception and a log message from each service, then compare the event payloads in GlitchTip with the same events in Sentry. Check the stack frames, the grouping of similar errors, the user and request context, and the custom tags. Verify that the environment tag is set on every event and that release values match the identifiers your deployment pipeline publishes, because release tracking and regression detection depend on them. For JavaScript and mobile applications, upload source maps or debug symbols to GlitchTip with your own build step and confirm that minified frames resolve to original file names and line numbers. Document any field that differs, and do not assume parity with Sentry for features you have not tested.
Plan for the parts that do not transfer with the SDK. Alert rules, integrations, team membership and project settings are configured on the server side, so they must be re-created in GlitchTip, and the GlitchTip installation documentation is the starting point for the self-hosted setup itself. Run both DSNs in parallel for a fixed observation window agreed by the incident and platform owners, and compare event counts and grouping for the same releases before you remove the Sentry DSN from production configuration. Keep the old Sentry DSN available for a documented rollback period, and record who approves the final switch.
Where error data lives and who controls it
Error events often contain stack traces, request details and user identifiers, so where they are stored and who can reach them matters as much as the features. The cards below compare Sentry SaaS, GlitchTip hosted at app.glitchtip.com and GlitchTip self-hosted in your own cloud or data center, and list the checks to run before you choose.
Sentry SaaS regional hosting
Sentry SaaS runs in regions that you select, and the region affects where event data is processed and stored. Ask Sentry in writing which components of your account, including organization settings, tokens and DSN keys, sit in which location, because a region choice that covers events alone can leave account data elsewhere. Confirm whether the region can be changed after creation and what happens to existing data if it cannot.
GlitchTip hosted at app.glitchtip.com
GlitchTip is also offered as a hosted service at app.glitchtip.com, which keeps the Sentry-compatible workflow while moving operations to Burke Software and Consulting. Your team still does not control the server, database or backup location, so it fits teams whose requirement is a smaller vendor relationship rather than full infrastructure control. Ask for the data location, subprocessors and deletion process in writing before sending production events.
Self-hosted GlitchTip in your own infrastructure
Self-hosted GlitchTip runs on servers or Kubernetes in your own cloud account or data center, so events, PostgreSQL data and backups stay where you place them. GlitchTip's backend is MIT licensed, which means you can review the code that handles your data. Your team takes on patching, backup testing and access administration, which is the main trade-off against a hosted option.
Identity and single sign-on
Decide who signs in to the error tracker and how: local accounts, a corporate identity provider or no shared access at all. Sentry's plan structure can gate SSO behind higher tiers, so check which tier includes it before you compare prices. For a self-hosted GlitchTip, confirm which login methods the release you deploy supports and whether accounts can be tied to your central directory.
Role-based access to event data
Error events can carry request parameters, headers and user fields that include personal data or secrets. Map who may view issues, change project settings, rotate DSN keys and export data, then compare that model with Sentry's team and role settings and GlitchTip's organization and project permissions. Test the model with a non-production project before you rely on it.
Audit trail and compliance evidence
Auditors look for logs of administrative actions, access reviews and retention enforcement, and they issue the reports on those controls. DeployOpen prepares the systems, configuration and evidence for an assessment, but it does not issue audit reports, attestations or certifications. Ask Sentry and the GlitchTip hosting provider which audit logs they provide and how long they keep them, and plan to collect the equivalent evidence yourself when you self-host.
Why self-hosted Sentry is not the open-source option
The first question for a buyer with an open-source policy is licensing, not features. Sentry's self-hosted edition is source-available under the Functional Source License (FSL), which means the code can be read and run under its terms, but it is not an open-source license in the sense most open-source policies use. Those policies usually list approved licenses by SPDX identifier, and FSL is not on the usual approved lists. GlitchTip's backend, by contrast, is published under the MIT license, which most open-source policies accept without exception. Before you plan a self-hosted deployment, put the FSL text and the MIT text in front of the people who own your license approval process and ask them to classify each one under your policy.
Confirm the license terms with your own legal team rather than relying on a summary, including what the FSL permits for internal use, how it treats competing offerings, and whether your intended use, such as running it for internal teams or for customers, falls inside those permissions. Ask them to record the decision as a dated entry in your software inventory, along with the version you plan to deploy. The license of a component can change between releases, so the check should cover the exact release and the upstream repository you will install from, not a general statement about the product. GlitchTip's MIT license for the backend should be checked the same way, including any frontend or add-on components that your deployment pulls in, because each one carries its own terms.
What buyers ask before moving from Sentry to GlitchTip
What drives the total cost of moving from Sentry to GlitchTip?
The cost has three parts: the Sentry subscription you stop paying, the infrastructure and operations you start paying for, and the one-time migration work. On the GlitchTip side, the recurring costs are the servers or Kubernetes capacity, a PostgreSQL database (managed or self-run), optional Valkey or Redis, backups and on-call time for upgrades. The main one-time cost is project setup, SDK DSN changes, alert rebuilding and parallel running. GlitchTip's hosted plans are Free for up to 1,000 events per month, Small at $15 per month for 100,000 events, Medium at $50 per month for 500,000 events and Large at $250 per month for 3 million events, according to the GlitchTip website, so you can compare a hosted option against self-hosting. Ask any quote for line items by component so you can see who is paid for what.
How long does a switch from Sentry to GlitchTip take?
The timeline depends on how many projects and SDK integrations you have, how many alert rules and integrations must be recreated by hand, whether you need historical data, and how long you want both systems running in parallel. Application code changes are usually small because GlitchTip works with Sentry client SDKs, so the main variable is the number of services whose DSN must be repointed and verified. Agree a duration only after a written scope lists the projects, environments and integrations involved. No fixed duration is given here because none was supplied for this migration.
Can our own team migrate from Sentry to GlitchTip without a partner?
Yes, a team with Linux, Docker or Kubernetes, and PostgreSQL experience can install GlitchTip and repoint SDK DSNs itself, using the GlitchTip installation documentation. The harder parts are data export from Sentry, rebuilding alert rules and integrations, and operating the stack afterward. Check whether you have on-call capacity for patching and backups, because those recur after cutover. A team that lacks any of these skills, or that must evidence controls for an assessment, may prefer a fixed-scope engagement.
Which Sentry features must be recreated by hand in GlitchTip?
Plan to recreate alert rules, notification routing, integrations and project or team settings manually, because these are not carried over automatically. Confirm each Sentry feature you rely on against GlitchTip's documented coverage before cutover. GlitchTip covers error tracking (exceptions, log messages and Content Security Policy violations), performance monitoring of slow requests and database calls, uptime monitoring with email or webhook alerts, and log search, according to its website. Features outside that list, such as session replay, should be confirmed with the vendor or tested in your own environment, and a separate tool may be needed for them.
Do we have to operate PostgreSQL and Valkey or Redis ourselves?
GlitchTip requires PostgreSQL 14 or later, and Valkey or Redis 7 or later is an optional add-on. You do not have to run the database yourself, since GlitchTip's Helm chart documentation recommends an external managed database, and that is a common choice for Kubernetes deployments. Running PostgreSQL in-house means you own backups, restore tests, patching and capacity planning. Valkey or Redis is needed only when you scale to separate web and worker services, so ask whether your chosen layout requires it before you buy managed capacity.
What hardware does GlitchTip need compared with self-hosted Sentry?
GlitchTip's installation documentation lists a minimum of 256 MB RAM for the all-in-one setup and recommends 512 MB RAM on x86 or arm64, with disk size depending on traffic and event size. Those figures describe the GlitchTip application, not the database, so size PostgreSQL separately for your event volume and retention. Docker Compose suits a single server, and the Helm chart suits Kubernetes. Ask any vendor or partner to size the environment against your expected events per month, retention period and peak load in writing.
Does moving to GlitchTip change how our data is handled and controlled?
Self-hosting moves the stored events, project configuration and account data into infrastructure you control, which matters for data residency and access review. GlitchTip's backend is MIT licensed, so you can inspect the code and keep the platform under your own governance. Whether a given environment meets a specific regulation depends on your controls, configuration and assessment, and DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Confirm your obligations with your compliance lead and an independent auditor.
When should we bring in an implementation partner for this move?
Bring in a partner when the migration has to fit a compliance evidence plan, when you run many projects across several teams, or when your in-house team cannot cover setup, backups, upgrades and on-call. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. A quote follows from that written scope.
Cost components on each side of the decision
Sentry SaaS and self-hosted GlitchTip bill different things: one charges for plan tiers and event quotas, the other for infrastructure and the people who run it. Each card below names one cost component, who gets paid for it, and whether it recurs, so you can ask the right questions before comparing totals.
Sentry plan fees and event quotas
On Sentry SaaS, the recurring cost is the plan fee plus any event volume beyond the included quota. Check which features sit behind higher tiers, how retention is set, and whether single sign-on or audit features require a specific plan. Ask Sentry for the current rate card in writing, because quotas and prices change and cannot be assumed from older comparisons.
GlitchTip hosted plan prices
If you choose GlitchTip's hosted service instead of running it yourself, the GlitchTip website lists a Free plan for up to 1,000 events per month, with paid tiers that scale by event volume. This keeps the cost model close to Sentry's, but you still pay per event tier. Confirm current prices and whether a BAA is needed for your data before signing.
Self-hosted infrastructure and PostgreSQL
Self-hosting GlitchTip moves the bill to servers or Kubernetes capacity, plus a PostgreSQL 14 or later database. Costs rise with event volume, retention and disk size. A managed external database is the usual recommendation with Helm, which adds a recurring service fee but removes database operations from your team. Ask your cloud provider or data center for a quote on both options.
Upgrades, backups and patching
Each upgrade of GlitchTip and PostgreSQL, along with backup and restore testing, is recurring labor whether you buy it from an internal team or a partner under a retainer. Budget for test environments and rollback plans. Errors from upgrades usually surface as broken ingest, so ask any implementation partner how they will verify that the Sentry SDK still delivers events after each change.
On-call time for error alerts
Self-hosting adds on-call work: someone must respond when the ingest service, worker queue or database degrades, and that work does not appear on any vendor invoice. Sentry SaaS shifts this to the vendor's uptime. Estimate how many engineer hours per month your team can give to this, and whether your existing on-call rota can cover a new service without extra hiring.
One-time migration and alert re-creation
Moving projects, DSNs and alert rules to GlitchTip is one-time work. Sentry SDKs are kept, so most effort goes into project setup, re-creating alert rules and integrations by hand, and running both systems in parallel for a period. Scope this as a fixed piece of work with a written list of projects, alerts and history to export, so the one-time cost does not grow during the project.
How a move from Sentry to GlitchTip proceeds
The sequence moves error tracking from Sentry SaaS to self-hosted GlitchTip without a gap in coverage, so each application reports to GlitchTip only after it has been proven there and the Sentry project can be retired with a clear record of what was moved.
Inventory projects, teams and alert rules
The engineering lead lists every Sentry organization, team, project, environment and DSN, along with the alert rules, issue ownership rules, release tracking setup and integrations (such as chat and ticketing) attached to each one. Owners of each application confirm which Sentry SDK and version they use, because SDK compatibility decides whether the same client code can point at GlitchTip. The step is done when a written inventory maps each Sentry project to an owning team, an application and a list of the alerts that must be re-created by hand.
Export what the Sentry API allows
The platform team pulls issues, events and project settings through the Sentry web API, using the API host for the region where the organization is hosted and following cursor pagination and rate limit headers. Exports are stored in a location the security team controls and labeled by project. Teams should confirm with Sentry which fields the API returns and which history will not transfer, since alert rules and integrations usually have to be re-created manually. The step is done when each project has an export file and a short note of what was not captured.
Stand up GlitchTip on your infrastructure
The platform team deploys GlitchTip with Docker Compose on a single server for a small footprint, or with the Helm chart on Kubernetes, where the documentation recommends an external managed PostgreSQL database. GlitchTip requires PostgreSQL 14 or later, and Valkey or Redis 7 or later is optional. Backups, TLS, access control and outbound email or webhook delivery are configured at this stage, and the team confirms the current version against the release page before deploying. The step is done when the instance starts, accepts a test login and sends a test alert.
Point staging DSNs at GlitchTip
Engineers create matching organizations and projects in GlitchTip and change the DSN in a staging build or configuration to the new GlitchTip project, keeping the existing Sentry SDK code in place. They trigger known test exceptions, log messages and a slow request to confirm that events arrive, group correctly and show the expected release, environment and user context. The step is done when each staging application produces the same issue types in GlitchTip that it produces in Sentry, and any SDK feature that does not appear is logged as a gap.
Run both platforms in parallel
Production applications send events to Sentry and GlitchTip at the same time, either by initializing a second client or by using a configuration that supports multiple DSNs, depending on the SDK in use. On-call engineers compare issue counts, grouping and alert timing between the two for a period agreed in the migration plan. Differences in grouping, sampling or missing features are recorded with the owning team. The step is done when the owners sign off that GlitchTip reports the errors they depend on for each application.
Re-create alerts and integrations
The on-call lead rebuilds each alert rule in GlitchTip, including recipients, thresholds and escalation paths, and reconnects notifications through email or webhook. Uptime checks and scheduled heartbeat pings that were tied to Sentry monitoring are configured in GlitchTip's uptime monitoring, and the team confirms that a deliberate failure triggers the expected alert. Anything GlitchTip does not cover, such as Sentry-only features, is listed with a decision on the alternative. The step is done when every alert in the inventory has a GlitchTip equivalent, a test result and a named owner.
Cut over and decommission Sentry
The team removes the Sentry DSN from production configuration so that GlitchTip becomes the only error destination, and the change is recorded in the deployment history for each application. After the owners confirm that no events are arriving at Sentry and the exports are archived, the Sentry projects and any Sentry-connected tokens are revoked according to the contract terms. Teams should confirm with Sentry how data retention and deletion work for the archived organization. The step is done when production events reach only GlitchTip, the Sentry access is removed and the migration record is filed with the security and compliance teams.
When GlitchTip will not replace Sentry on its own
Keep Sentry, or add tooling beside GlitchTip, when your team depends on Sentry-specific workflows or integrations that are not confirmed in GlitchTip. Start by listing every place Sentry is wired into your delivery and support process: release tracking tied to deploys, suspect commits, issue assignment rules, ownership mapping, custom dashboards, marketplace integrations with ticketing or chat tools, and any internal scripts that call Sentry's web API. For each item, ask whether GlitchTip offers the same behavior, a close equivalent, or nothing. Where the answer is unclear, confirm it with the GlitchTip maintainers or in your own test instance rather than assuming parity. Treat any item with no equivalent as a decision point, because the cost of rebuilding it may outweigh the licensing savings.
Session replay is the most common reason to keep a second tool. GlitchTip covers errors, performance, uptime and log search, but it does not replace replay of user sessions alongside console output and network activity. If replay is part of your support or QA practice, plan to run it separately. The Sentry vs SigNoz comparison and the separate OpenReplay page cover that path, and the errors can stay in GlitchTip while replay runs elsewhere. If your teams need a single tool for traces, logs, metrics and errors together, the question shifts to a full observability stack, which is a different decision from error tracking. Read the Sentry vs SigNoz page before committing, since adding a broader platform changes your ingest, storage and on-call footprint.
Run a proof of concept before you cut over. Point a non-production service at a GlitchTip instance by changing only the DSN, then check that events from each SDK language you use arrive with stack traces, breadcrumbs, release and environment tags, and user context as your alerts expect. Re-create one real alert rule and one integration, confirm that uptime checks and scheduled pings behave as your on-call process requires, and load test at your expected event volume against the PostgreSQL and worker sizing you plan to run. Record every feature that the team used in Sentry and marks as failed or missing. That list, not a feature matrix, decides whether GlitchTip replaces Sentry on its own or sits beside it.
How DeployOpen helps evaluate and move error tracking
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so error tracking can be evaluated and moved without guesswork. Work begins with a written scope that covers which Sentry projects, SDKs and features matter to your teams before any change is made.
How we scope
- We inventory the Sentry projects, client SDKs, alert rules and integrations your teams depend on today.
- We map each feature to GlitchTip coverage and mark the gaps that need a decision or workaround.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy GlitchTip in your cloud account or data center using Docker Compose or the Helm chart.
- We connect PostgreSQL 14 or later, optional Valkey or Redis 7 or later, and separate web and worker services where scaling needs them.
- We test SDK compatibility by pointing a staging project's DSN at GlitchTip and checking events, performance data and uptime alerts.
How we hand over
- We document the deployment, configuration, backup and restore steps, and the alert rules re-created by hand.
- We run Sentry and GlitchTip in parallel for an agreed period and record how event counts and grouping compare.
- We deliver a written handover covering access, upgrade steps and the feature gaps your team accepted.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can review each GlitchTip release against your deployment before you upgrade in production.
- Confirm with us which evidence your compliance assessors need, since DeployOpen prepares controls and records but does not issue audit reports.
