monitoring
Sentry logo

Should I self-host Sentry?

YESworth it

GlitchTip speaks the Sentry SDK protocol and fits on a normal VPS. Sentry's own self-host wants 16GB and a small ops team — the honest self-host answer is the compatible lightweight, and it breaks even in about two months.

The math (nothing hidden, including your time)

Sentry (Team)$26.00/mo
VPS share + storage−$2.50/mo
Your maintenance: 30 min/mo at $20/h−$10.00/mo
Net saving$13.50/mo
Setup: 90 min measured (one-time)$30.00
Break-even2.2 months
Markup Index (price ÷ real self-host cost)2.1×

Price: source, checked 2026-08-06. Inputs are stored in git; every number above is derived, never hand-written.

What you lose

  • Sentry's deep tracing/profiling/replay product — GlitchTip is errors done well, not the whole observability suite
  • SaaS-side data retention muscle

What you're paying Sentry for

  • error tracking (Sentry SDKs)
  • issue grouping & alerts
  • performance traces (basic)
  • uptime checks
GlitchTip running from the boot-verified compose file
GlitchTip, running from the compose file on this page — screenshot from our verified instance, not marketing material.

Ranked alternatives

Error tracking that speaks the Sentry SDK protocol, so your code keeps its instrumentation and changes one DSN.

burke-software/GlitchTip · ★ 172 · last commit 181d ago · MIT

Hardware

Runs comfortably on a real VPS (2 GB+).

The tested compose file (our evidence, CI-booted)

# GlitchTip — Sentry-compatible error tracking that fits on a normal VPS (replaces Sentry's
# Team plan; Sentry's own self-host wants ~16GB and a dozen containers — GlitchTip is the
# sane answer)
services:
  glitchtip-web:
    image: glitchtip/glitchtip:latest
    container_name: glitchtip-web
    restart: unless-stopped
    depends_on:
      glitchtip-db:
        condition: service_healthy
      glitchtip-redis:
        condition: service_healthy
    environment: &gt-env
      DATABASE_URL: postgres://glitchtip:glitchtip@glitchtip-db:5432/glitchtip
      REDIS_URL: redis://glitchtip-redis:6379
      SECRET_KEY: 2b1e6f9c8d7a5b4c3e2f1a0d9c8b7a6f5e4d3c2b1a0f9e8d # throwaway test value
      GLITCHTIP_DOMAIN: http://localhost:8088
      EMAIL_URL: consolemail://
      ENABLE_USER_REGISTRATION: "true"
    ports:
      - "8088:8000" # glitchtip serves on 8000
    healthcheck:
      # python-slim image: no curl/wget, but python is right there
      test: ["CMD-SHELL", "python3 -c \"import urllib.request;urllib.request.urlopen('http://localhost:8000/_health/')\""]
      interval: 5s
      timeout: 5s
      retries: 36
      start_period: 30s

  glitchtip-worker:
    image: glitchtip/glitchtip:latest
    container_name: glitchtip-worker
    restart: unless-stopped
    command: ./bin/run-celery-with-beat.sh
    depends_on:
      glitchtip-db:
        condition: service_healthy
      glitchtip-redis:
        condition: service_healthy
    environment: *gt-env
    # No worker healthcheck: celery's inspect ping is unreliable as a container probe
    # (broker registration races it forever). The web container's /_health/ gate plus
    # restart: unless-stopped is the honest signal here.

  glitchtip-db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: glitchtip
      POSTGRES_DB: glitchtip
    volumes:
      - glitchtip-pg:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U glitchtip"]
      interval: 5s
      timeout: 5s
      retries: 12

  glitchtip-redis:
    image: redis:7-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      interval: 5s
      timeout: 5s
      retries: 12

volumes:
  glitchtip-pg:

Want a guided install instead? caniselfhostit.com/sentry has AI-agent prompts that assume a bare machine — that's their half of the stool, and it's good.

Verification

Protocol v1 · verified by zernonia on 2026-08-10 · setup measured at 90 min · AI assistant: claude-code (allowed & stated)

What broke

  • The container serves on 8000, not the 8080 several guides claim — map and probe accordingly
  • python-slim image has no curl/wget; the healthcheck probes /_health/ with python urllib
  • Celery worker needs its own container with the same env — errors ingest but nothing processes without it; don't healthcheck it with celery inspect ping, which races broker registration forever
Full timed log
# Timed setup log: Sentry → glitchtip

**Protocol:** v1 · **Verified by:** zernonia · **Date:** 2026-08-10
**Assistant:** claude-code · **Environment:** containerized runner, 2 vCPU class, Docker 29.3 / Compose v5.1

## Timeline

| Step | Time |
|---|---|
| Read upstream docs, draft compose with healthcheck | ~30 min |
| **Boot: all services healthy in 13 s (measured, `compose up --wait`)** | — |
| Endpoint-level workflow check (login/health/API serve) + re-run from clean volumes | ~30 min |
| **Total: ~90 min** | |

Boot and endpoint checks are machine-verified; `setup_min` is the wall-clock total for this
session including authoring, diagnosis and re-runs. Endpoint-level ≠ full human UI workflow —
dispute anything that doesn't reproduce (CONTRIBUTING.md).

## What broke

- The container serves on 8000, not the 8080 several guides claim — map and probe accordingly
- python-slim image has no curl/wget; the healthcheck probes /_health/ with python urllib
- Celery worker needs its own container with the same env — errors ingest but nothing processes without it; don't healthcheck it with celery inspect ping, which races broker registration forever

## Verdict-relevant notes

- SDK setup is unchanged from Sentry: swap the DSN.

Verdict history

  • 2026-08-10: unscored → YES — Initial verdict: GlitchTip speaks the Sentry SDK protocol and fits on a normal VPS. Sentry's own self-host wants 16GB and a small ops team.