Where Sentry cost ends and GlitchTip infrastructure cost begins
A Sentry renewal or plan change is forcing a cost review, and the first question is whether a self-hosted replacement is cheaper at your volume. Self-hosting trades a Sentry subscription for infrastructure and labor, so the answer depends on how many events you send each month and how long you keep them. Neither side can be estimated from the outside, so the comparison has to start from your own numbers. For the Sentry side, take plan prices, event quotas, retention limits and the plan that gates SSO from your current Sentry invoice and plan page, not from memory or from a competitor's comparison. Note the event volume you were billed for over the last few billing cycles, because that is the figure GlitchTip's hosted tiers are priced against. As a hosted reference point, GlitchTip's website lists 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, with a BAA available on request on the Large tier.
The self-hosted side has different cost components. GlitchTip needs PostgreSQL 14 or later, and Valkey or Redis 7 or later is optional. Its installation documentation lists 256 MB RAM as the minimum for the all-in-one setup and recommends 512 MB RAM on x86 or arm64, but disk size and worker capacity depend on your traffic and event size, so confirm those figures with a sample of your own events. Your recurring costs are the servers or cluster capacity, backups, storage growth and the on-call time to patch and upgrade. Your one-time costs are the initial setup, integration of your Sentry client SDK DSNs and any managed database onboarding. Ask any implementation partner for a written scope that lists which of these items are included and which remain with your team.
Cost components on the Sentry and GlitchTip sides
This table lists each cost component on the Sentry SaaS side and the self-hosted GlitchTip side, with who is paid, whether the cost is one-time or recurring, and what drives it. Use it to build a quote request and to see where your own volume, retention needs and staffing will move the total. Plan prices and event quotas should be checked on the vendor's current pricing pages before you compare.
| Cost component | Sentry SaaS side | Self-hosted GlitchTip side | One-time or recurring |
|---|---|---|---|
| Subscription or plan fees and event overage | Paid to Sentry per plan tier, with overage tied to event volume. Confirm current plan terms with Sentry. | No license fee for the GlitchTip backend, which is MIT licensed. Hosted GlitchTip plans are a separate option if you do not self-host. | Recurring |
| Retention and feature tiers (SSO gating) | Retention limits and access to features such as SSO depend on the plan. Confirm which tier includes SSO and the retention you need. | Retention is set by your own storage and cleanup policy. Access controls are configured by your team on the instance. | Recurring |
| Hosting compute | Included in the SaaS fee. You do not size or patch servers. | Web and worker services run on your servers or cluster. The documented minimum is 256 MB RAM for the all-in-one setup, and 512 MB RAM is recommended. Real sizing depends on event rate and event size. | Recurring |
| PostgreSQL (managed or self-run) | Not visible to you. Included in the SaaS fee. | Required, version 14 or later. A managed database adds a monthly fee. A self-run database adds patching, tuning and storage time. Storage grows with retained events. | Recurring |
| Optional Valkey or Redis 7 or later | Not applicable. | Optional add-on. Needed only if you run separate web and worker services at scale. Adds one more service to run and monitor. | Recurring |
| Backups and disk | Covered by the vendor. Ask Sentry what it guarantees for data recovery. | Your team or DeployOpen would set up database backups, restore tests and disk growth alerts. Cost depends on retention length and backup target. | Recurring |
| Setup and migration | Low effort for a new project because you add a DSN to each application. Migrating existing history and alert rules takes time. | Installation with Docker Compose for a single server or the Helm chart for Kubernetes, then project setup and DSN changes. Effort rises with the number of projects and alert rules to recreate. | One-time |
| Upgrades and on-call time | Vendor handles platform upgrades. Your team still updates SDKs and responds to alerts. | Your team applies GlitchTip and PostgreSQL upgrades and handles outages. Budget for on-call time for the platform itself, not only for application errors. | Recurring |
| Internal skills and external support | Few platform skills needed. Support is tied to the plan. | Needs staff who can run PostgreSQL, containers and TLS. External support is a fixed-scope or retainer agreement, quoted from your written scope. Ask for the support hours and response terms in writing. | Recurring |
What moves the Sentry versus GlitchTip comparison
Six parallel drivers decide whether Sentry SaaS or self-hosted GlitchTip costs less for your team. Several of them push in opposite directions, so model each one against your own event volume, retention and staffing before comparing totals.
Monthly event volume against plan tiers
Sentry SaaS prices rise with the events you send each month, so volume is the first number to pull from your current invoice. GlitchTip's hosted plans step from Free at 1,000 events per month to Large at 3 million events, but a self-hosted instance has no per-event fee, so its cost moves with infrastructure and storage instead. Higher volume pushes the SaaS bill up and pushes self-hosted sizing up more slowly. Ask Sentry for the quota behind your current plan and check how overage is billed.
Event size and payload content
Large stack traces, breadcrumbs, request bodies and attachments make each event heavier, which increases database rows, disk writes and backup size on your own servers. Quota-based pricing counts events, so large events do not raise the SaaS bill directly, but they do raise self-hosted storage and PostgreSQL load. Trim payloads in the SDK configuration and measure average event size in a pilot before sizing disks.
Retention period required
Longer retention is the main cost driver for a self-hosted instance because every stored day adds to PostgreSQL storage, backup volume and restore time. Confirm the retention window your audit or incident process needs, not the window you would like to have. Sentry SaaS retention depends on your plan, so check whether a longer window is a plan upgrade. Set retention in GlitchTip to match the policy, and review it with the team that owns backups.
Number of projects and teams
Each project adds a DSN, alert rules, integrations and permissions to maintain. Many small projects cost more to administer than their event counts suggest, and that work is the same whether the tool is hosted or self-hosted. Count projects, teams and alert routes now, and agree who owns project setup in GlitchTip. A migration is a good point to remove unused projects before they are re-created.
Availability needs and deployment shape
A single server with Docker Compose suits a small team that accepts a short outage during patching. Kubernetes with the Helm chart, separate web and worker services and an external managed PostgreSQL database adds infrastructure and a platform team's time, but gives you more room to scale and recover. Requirements listed in GlitchTip's installation documentation are a starting point only. Confirm your uptime expectation and where errors must still arrive while the tool is down.
SSO, compliance and in-house skills
SSO and audit requirements shape cost because they may force a plan tier or a configuration effort that a self-hosted instance must cover itself. Check which SSO and audit features your Sentry plan includes and which your GlitchTip deployment will need through your identity provider. Staff time is the cost most often missed: someone must patch PostgreSQL, rotate secrets, test restores and answer on-call pages. Price that time against your existing platform team rather than assuming it is free.
How to build the cost model with your own numbers
This sequence turns Sentry's bill and your real event traffic into a side-by-side 12-month and 36-month total for self-hosted GlitchTip, with the labor and infrastructure lines written down so each figure can be checked.
Pull current plan and event volume from Sentry
The finance or billing owner exports the current Sentry plan, the monthly event quota, the overage charges and the invoice history for the last 12 months. Engineering confirms which event types count against the quota, including errors, transactions and any attachments or replays on your plan. Write these into a single sheet with one row per month. Done means every row traces back to an invoice or a billing-page screenshot, and you can state the plan's annual cost from the contract, not from memory.
Measure average event size and peak load
An application or platform engineer samples recent events from the Sentry project settings and the SDK traffic to estimate average payload size, the share of events with stack traces and breadcrumbs, and the busiest hour of the week. These numbers drive PostgreSQL disk growth and worker sizing, so record them per project. Done means you have an average size per event, a peak events-per-minute figure and a note on which projects produce most of the volume.
Define retention, projects and sampling
The platform owner decides how long events and issues must be kept, which teams and projects will move to GlitchTip, and whether any sampling reduces volume before it is sent. Retention decisions should reflect your own policies and any audit or contractual obligations, which the compliance lead confirms in writing. Done means a one-page table lists each project, its retention period, its expected monthly event count and any sampling rate, so the storage calculation uses agreed inputs.
Price the GlitchTip infrastructure
Using the agreed volume and retention, the platform team sizes the infrastructure: a managed PostgreSQL 14 or later instance with enough storage for the retention window, one or more web services, one or more worker services, and an optional Valkey or Redis 7 instance if you need it for caching or queuing. The GlitchTip installation documentation lists minimum memory for the all-in-one setup, so use it only as a floor. Ask your cloud provider or data center team for written quotes on compute, managed database, storage, backups and egress. Done means each line item has a unit price from a quote and a monthly total.
Add labor for setup, upgrades and on-call
Estimate the internal effort to deploy GlitchTip with Docker Compose or the Helm chart, migrate projects and alert rules, operate backups, apply GlitchTip and PostgreSQL upgrades, and respond to alerts about the error pipeline itself. Record who performs each task, their loaded hourly cost and how many hours per month they are expected to spend, with a separate one-time estimate for the migration. If you want an external party to plan, implement or support the stack, request a written fixed-scope quote from DeployOpen and from any other implementation partner. Done means the labor lines are tagged one-time or recurring and each has a named owner.
Build the 12-month and 36-month totals
Place the Sentry cost and the GlitchTip cost side by side for two horizons, 12 months and 36 months. Keep one-time costs (migration, initial setup, parallel running) separate from recurring costs (plan or hosting fees, infrastructure, support hours), and show the cumulative total at each horizon. Include a sensitivity row for higher event volume, because Sentry overage and GlitchTip storage both scale with it. Done means the sheet produces two totals per option and a break-even month, and every input cell cites a quote, invoice or internal estimate.
Validate the model against written quotes
Before a decision, send the assumptions to Sentry and your hosting providers to confirm pricing, quota and feature gating for your plan, and ask DeployOpen for a written scope and quote covering any implementation or support you plan to buy. Compare each vendor's quote with the figure in your model, then update the sheet where they differ. Done means every recurring and one-time line has either a written quote or an internal estimate labeled as such, and the signed-off model is stored with the decision record.
What GlitchTip needs to run at your event volume
GlitchTip is a Django application with its backend published under the MIT license, and it needs PostgreSQL 14 or later as its data store. Valkey or Redis 7 or later is an optional add-on. You can run everything as a single service on one server with Docker Compose, or split the web and worker services so background event processing scales apart from the request handling. On Kubernetes, the Helm chart is the documented route, and the installation guide recommends pointing it at an external managed database rather than a database inside the cluster. The installation documentation lists 256 MB of RAM as the minimum for the all-in-one setup and recommends 512 MB on x86 or arm64, but those figures describe a starting point, not a sizing for your traffic.
Three infrastructure drivers decide what your monthly bill looks like once you leave SaaS. The first is database sizing: PostgreSQL holds every event, issue and project record, so its CPU, memory and IOPS needs grow with event rate and with how many queries your team runs against history. The second is disk growth, which the GlitchTip documentation ties to traffic and event size. Stack traces, breadcrumbs and request payloads vary widely between applications, so estimate from a sample of your own events rather than from a generic average. The third is backup frequency, which sets your recovery point and the storage you must pay for. Measure all three in a staging run that replays realistic event volume for at least one full retention window before you size production.
Sentry SDK compatibility matters most at the edge of the system. GlitchTip states that it accepts error data from applications through Sentry's open-source SDKs, so the instrumentation in your services can stay as it is and only the DSN changes. That keeps client-side change cost low, but it does not remove the server-side work of hosting, patching and backing up the database. Before you commit, confirm with GlitchTip which Sentry SDK versions and event types your stack uses, test one service end to end, and ask your platform team who owns the PostgreSQL instance, its upgrades and its restore testing. Those answers, not the SDK, will dominate your ongoing infrastructure cost.
Questions buyers ask about Sentry and GlitchTip costs
Is self-hosting GlitchTip cheaper than paying for Sentry?
It can be, but the answer depends on your event volume and on what your team charges for its time. GlitchTip's software is MIT licensed, so there is no license fee for the backend. The recurring costs are the server, PostgreSQL storage, backups, outbound networking and the engineering hours to run it. The hosted GlitchTip plans show what a managed service costs at small volumes: Free covers up to 1,000 events per month, Small is $15 per month for 100,000 events, Medium is $50 per month for 500,000 events and Large is $250 per month for 3 million events. Compare those published figures against your own infrastructure and staff time, not against Sentry's list prices alone. Sentry's plan prices and quotas should be taken from Sentry's current pricing page at the time you decide.
What drives the effort of running GlitchTip in-house?
The main drivers are how many events you ingest, how long you keep them, how many applications send data, and how much high availability you need. GlitchTip runs as a single service for small installs, or as separate web and worker services when you scale. Each added event stream adds database writes, storage and worker load. Running a single server with Docker Compose is simpler than a Kubernetes deployment with the Helm chart, which the installation documentation recommends pairing with an external managed database. Ask your team which of these choices they plan to make before estimating effort.
How long does a GlitchTip setup take?
No duration is published for this work, so ask for a fixed scope before you plan a date. The scope should state which environments are covered, how many applications will send errors, whether PostgreSQL is managed or self-run, how the Sentry SDKs will be repointed, which alert rules and integrations must be recreated, and whether a parallel run is included. Once those items are written down, the timeline can be agreed in writing. Most engagements are fixed-scope, so the agreed deliverables and dates are the figure to rely on.
Can a small team set up GlitchTip without outside help?
A team with Linux, Docker and PostgreSQL experience can usually run a single-server GlitchTip install using the documented Docker Compose path. The work becomes harder when you need high availability, separate worker scaling, Kubernetes operations, or an audit-ready backup and restore process. Requirements are modest on paper: the all-in-one setup lists a minimum of 256 MB RAM, and the documentation recommends 512 MB RAM on x86 or arm64, with disk depending on traffic and event size. Decide honestly whether anyone on your team will own upgrades and on-call responses for error tracking before choosing to run it alone.
What skills and infrastructure does GlitchTip need from my team?
Plan for four areas. First, PostgreSQL 14 or later, including tuning, connection handling, and restore testing. Second, DNS records and a public hostname for the ingestion endpoint. Third, TLS certificates for that hostname, renewed on a schedule. Fourth, backups of the database and any stored attachments, with a tested restore procedure. Valkey or Redis 7 or later is optional and only needed for the add-on setup. Confirm each item against the installation documentation for the version you deploy, and check who holds each responsibility in your on-call rota.
How are GlitchTip upgrades handled, and who pays for them?
Upgrades are a recurring cost because the project publishes new releases on GitLab. For example, GlitchTip v6.1.8 was released on June 5, 2026. Each upgrade needs a review of the release notes, a test in a non-production copy, a database backup taken beforehand, and a rollback plan. Your internal staff pay this cost if they run the upgrades. If you use DeployOpen, upgrades, backups and documentation are part of the ongoing support and retainer options, which are agreed in writing before work begins. Ask any provider how often they upgrade, how they test, and how long a rollback takes.
Which costs are one-time and which recur when self-hosting GlitchTip?
One-time costs include planning, initial installation, SDK repointing, recreating alert rules and integrations, and the parallel run. Recurring costs include the server or Kubernetes capacity, managed or self-run PostgreSQL, storage that grows with retention, backups, monitoring of the GlitchTip host itself, certificate renewal, upgrades, and on-call time. Retention drives storage growth more than anything else, so set a retention period before you size disks. Treat staff hours as a recurring line, not a one-off.
What should I ask for in a quote for a GlitchTip migration?
Ask for a written scope that lists the applications and SDKs to repoint, the number of projects and teams, the event volume and retention you plan for, and the hosting model, such as Docker Compose on one server or Helm on Kubernetes. Request the deliverables in detail: installation, configuration, backup and restore testing, documentation, and handover. Ask which items are fixed-scope, which are optional retainer services such as upgrades and continuous support, and what is excluded, including Sentry data export and rebuilt alert rules. DeployOpen does not publish a price list, and a quote follows from the written scope.
When the comparison favors staying on Sentry
Staying on Sentry SaaS is the better choice when the cost of running error tracking yourself exceeds the cost of the subscription. That tends to be true for small teams with no on-call rotation for infrastructure, for organizations where no one owns PostgreSQL backups and upgrades, and for teams whose event volume is low enough that a hosted plan is cheap relative to the engineering hours a self-hosted instance would consume. Confirm the current plan prices, event quotas and retention limits directly with Sentry, since those change, and compare them against the internal hours you would commit to patching, monitoring and restoring a self-hosted service.
Existing integrations are a second reason to stay. If your issue tracker, chat tools, release pipeline, source control links and alerting workflows are built around Sentry's native integrations and its suggested fixes features, moving them has a cost that does not appear on a hosting invoice. List every integration and webhook that consumes Sentry data, then check which ones GlitchTip supports and which you would need to rebuild. The same applies to teams whose SDK configuration, source map uploads and release tagging are already automated, because changes there touch every service.
The Sentry self-hosted package is a different trade-off from both options discussed here. It is designed for a specific scale and carries its own hardware, upgrade and support demands, so it does not remove operational work the way a hosted plan does. Teams that need the Sentry product surface but want to keep data on their own servers should review the sibling pages on Sentry SaaS against self-hosted Sentry and on the Functional Source License before deciding. Staying on SaaS may still be right for a team that wants the feature set without the operational work, and that choice deserves a documented review rather than a default.
How DeployOpen scopes a fixed-price GlitchTip implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For Sentry cost vs self-hosted GlitchTip, we turn your current Sentry usage into a written scope covering the GlitchTip deployment, data handling and handover before any work starts.
How we scope
- Inventory current Sentry projects, SDK versions, event volumes and alert rules before estimating any work.
- Confirm where GlitchTip will run, whether Docker Compose on one server or Helm on Kubernetes with an external PostgreSQL.
- Agree deliverables, exclusions and timelines in writing, since most engagements are fixed-scope.
How we build
- Install GlitchTip with PostgreSQL 14 or later and size web and worker services to your measured event load.
- Point existing Sentry client SDKs at GlitchTip DSNs and verify errors, performance data and uptime checks arrive.
- Configure backups, retention settings and access controls, then test restores before cutover.
How we hand over
- Document the architecture, sizing assumptions, upgrade procedure and the Sentry features that GlitchTip does not replace.
- Provide a cost worksheet that lists PostgreSQL, compute, storage, backup and staff time as separate line items.
- Deliver runbooks for on-call staff and a record of alert rules re-created from the original Sentry configuration.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan GlitchTip upgrades against each release, such as the v6.1.8 release published on June 5, 2026, in a test environment first.
- Ask us to confirm what a retainer covers, how often upgrades are applied and who responds to incidents.
