Migrate your Sentry projects to GlitchTip in under an hour

In August 2026, three issues accumulated enough reports in the getsentry/self-hosted repository to form a clear migration signal. Issue #4301 documents a deadlock of the Kafka consumer ingest-monitors after upgrading to 26.4.1: the consumer group stays joined but CURRENT-OFFSET stops advancing. The direct consequence is that all cron monitors flip to error with missed backfill, and the Crons feature becomes inoperable organization-wide. The problem only manifests on instances with accumulated data (more than 1.2 million rows in sentry_monitorcheckin); restarting containers provides only a few minutes of relief. Issue #4306 reports that all Snuba consumers repeatedly print the error 'Failed to read directory /etc/sentry-options/values: No such file or directory' in an infinite loop — closed without an official fix with the status 'not planned'. Issue #4321 concerns version 26.4.2: seaweedfs-1 and web-1 containers are reported as unhealthy at startup on x86_64 installations, making Sentry impossible to start reliably. These three regressions combined form a solid argument for exiting the Sentry self-hosted update cycle, at least temporarily.

This guide assumes GlitchTip is already deployed and running on your VPS. If not, the article 'Self-hosting GlitchTip v6 on a VPS with Docker Compose' covers the installation from scratch — read it first. For the migration itself, you need three concrete things: admin access to your Sentry self-hosted instance (to read existing DSNs and export alert configurations), admin access to your GlitchTip instance (to create equivalent projects and retrieve new DSNs), and the list of environment variables or configuration files for each application that contains the SENTRY_DSN value or equivalent. The migration is done project by project. If you have five Sentry projects, you will create five GlitchTip projects and swap five variables. Budget around ten minutes per project the first time; subsequent ones take two to three minutes each.

GlitchTip does not reimplement the SDKs: it consumes the same wire protocol as Sentry, which means any official Sentry SDK works without modification. The most common languages and frameworks are natively covered. In Python, sentry-sdk integrates with Django, Flask, FastAPI and Celery. In JavaScript and TypeScript, @sentry/browser, @sentry/node, @sentry/nextjs and @sentry/vue work directly. In Ruby, sentry-rails and sentry-ruby are supported. Go has getsentry/sentry-go. PHP can use sentry/sentry-laravel or sentry/sentry-symfony. Java and Android have their official SDKs. The only option to disable in some SDKs is auto_session_tracking — GlitchTip does not support real-time session tracking, but this does not affect error reporting. The traces_sample_rate parameter for performance tracing is supported from GlitchTip v6.1 with DuckDB enabled.

Events do not arrive in GlitchTip. First check that the DSN is syntactically correct: the expected form is https://<key>@your-domain.com/<id>. If your GlitchTip instance is behind a reverse proxy, make sure the X-Forwarded-For and X-Forwarded-Proto headers are forwarded — a misconfigured proxy can return silent 400 or 413 errors on the application side. Check the GlitchTip container logs (docker compose logs web) to confirm reception. The DSN is rejected with a 401 or 403 error. Most often, the public key in the DSN does not match the target GlitchTip project. Each project has its own key — verify that you copied the DSN from the correct project. If the error persists, check that the organisation and project exist and that the account used has write permissions. Error grouping does not look like Sentry. GlitchTip uses its own fingerprinting algorithm. Errors of the same type will be grouped, but the correspondence with Sentry groups is not guaranteed — especially for exceptions with dynamic stacktraces. This is expected behaviour, not a bug. If you have custom fingerprinting rules in Sentry, recreate them in GlitchTip via the project 'Fingerprinting' option.

If you do not yet have a GlitchTip instance in production and want to leave Sentry self-hosted without switching to another complex tool, a 2 GB RAM VPS is enough to run GlitchTip v6 in all-in-one configuration. The complete installation — Docker Compose, nginx as reverse proxy, TLS certificate, environment variables — is documented in the dedicated article 'Self-hosting GlitchTip v6 on a VPS with Docker Compose'. Once the instance is ready, the migration from Sentry follows the procedure described in this article: create projects, retrieve DSNs, swap variables. The total time from VPS creation to receiving the first event in GlitchTip is generally under one hour, including installation and migrating two to three projects. For teams monitoring multiple production applications, this is a realistic migration window — with no service interruption on the application side, since the only visible step is a process restart after the variable change.