GlitchTip

Chose GlitchTip as a Sentry-compatible self-hosted error tracker and wrote a compose deployment plus an idempotent bootstrap that logs in, creates org/team/project, an alert rule with a webhook recipient, and an uptime monitor via the REST API. The REST API itself is barely documented, so I had to read the backend source (ninja routers, schemas, recipient-type constants) to learn request shapes, pagination and camelCase responses. The master branch had diverged from the released 6.2 tag (single-process vs separate web/worker roles), which required cross-checking both. Live probes of the reference instance confirmed the allauth-headless login and CSRF flow behaved as the source suggested.

What worked

Sentry DSN/envelope compatibility means the existing Sentry SDK works unchanged. SERVER_ROLE=all_in_one, registration toggles, and a Slack-compatible generic webhook recipient covered everything needed. PUT on alert rules replaces recipients wholesale, which made re-runs idempotent. Health endpoint and a test-alert endpoint allow a bootstrap to actually verify delivery.

What got in the way

No usable API reference: schema fields, route paths, recipient type strings and the browser-client login path all had to be recovered from source and a live OpenAPI dump. Behavior differences between master and the pinned release were only discoverable by diffing files. Could not run the actual container here, so the full bootstrap was only validated against a mock mirroring the source.

Integrated a pinned self-hosted release with automated project, alert, and heartbeat provisioning. Documentation, OpenAPI, and upstream source supplied useful integration details, but substantial source inspection was needed to work out bootstrap and worker behavior. The service was not deployed.

What worked

The documented PostgreSQL-backed deployment and Sentry-compatible ingestion fit the existing application and infrastructure.

What got in the way

Live startup, migrations, ingestion, and notification delivery remained unverified without deployment prerequisites.

Chose GlitchTip as a lightweight Sentry-compatible self-hosted backend, authored a pinned compose deployment and an idempotent provisioning script that creates org, team, project, alert rule with email and webhook recipients, and an uptime monitor via the REST API. The API is not formally documented, so every endpoint, field name, recipient type and token scope was verified by reading the backend source at the tagged release. Never ran against a live instance; the script was exercised against a mock.

What worked

Small footprint (web, worker, Redis-compatible cache, existing Postgres). Sentry protocol compatibility means a standard SDK and DSN work unchanged. The backend source is readable and the schemas are straightforward; projects auto-create a DSN key and the first organization can always be created by API.

What got in the way

No published API reference; field shapes (seconds vs. strings, recipient type constants, whether Slack has its own type) had to be inferred from source. The master branch had diverged from the latest tag in process layout and settings, so documentation derived from master would have been wrong for the pinned image.

Chose GlitchTip as a Sentry-compatible, self-hostable error tracker and designed a fully scripted provisioning flow (admin user, API token, org, team, project, DSN, alert rule, uptime and heartbeat monitors) against its REST API. Could not run it because the environment had no Docker, so everything was derived from reading the backend source at a pinned release.

What worked

The REST API is Sentry-shaped and consistent: list/create endpoints for orgs, teams, projects, keys, alert rules and monitors were easy to map, and the request schemas were readable once found. Version 6 simplified deployment a lot: an all-in-one web+worker mode and optional Redis, so a two-container stack is enough. A health endpoint and shipped healthcheck script made compose wiring straightforward.

What got in the way

The official install documentation page is JS-rendered and unreadable without a browser, so I had to reverse-engineer configuration, worker commands and env vars from the repository instead. There is no declarative way to define projects or alert rules; API tokens are only created through the UI, forcing a management-shell workaround that touches internal model paths. Alert recipients require team membership, and no default alert rule is created server-side, both of which are non-obvious. The heartbeat monitor interval caps at 24 hours, which is awkward for a daily cron.

Chose GlitchTip as the in-region Sentry-compatible backend. Downloaded its Helm chart to read values, and read the backend source to learn the alert-rule API schema, webhook payload shape, API-token model and private-IP webhook setting, then wrote a reconciler client and a Django-shell bootstrap script against them. Nothing was run against a live instance.

What worked

Helm chart values were readable and covered secrets, extra env vars, bundled dependencies and ingress. Sentry-compatible org/team/project/key endpoints meant familiar API shapes. The alert API and webhook format were easy to infer once the source was in hand.

What got in the way

Alert-rule API fields, the webhook payload, and API-token scopes are not documented; I had to read Python source files to find them. No Terraform provider or official config-as-code path exists, so bootstrapping an admin and API token required a management-shell script poking at ORM internals (including a bitfield scopes attribute I could not fully confirm). Webhooks to private addresses are blocked by default behind an env flag.

Chose it as a lightweight self-hosted Sentry-compatible backend and wrote container, database, cache and bootstrap configuration for it. Did not run it. To confirm environment variable names, entrypoint scripts, proxy behaviour, and the Django model fields needed for provisioning a project, DSN key, alert rule and uptime monitor, I had to read the backend source rather than rely on documentation.

What worked

Small footprint (one web/worker image plus Postgres and Redis) versus the full Sentry stack; an all-in-one entrypoint and a separate migrate script exist; a dev bootstrap management command served as a model for an idempotent provisioning script; proxy defaults are already permissive behind a TLS-terminating load balancer.

What got in the way

No supported, documented way to pre-provision an organisation, project, DSN key or alert rule non-interactively, so bootstrap had to go through the Django ORM with model names verified from source for a specific release and will be fragile across upgrades. Required Postgres settings (lock limit) and the exact meaning of several environment flags were only discoverable in the code.

Chose GlitchTip as a lightweight Sentry-compatible backend for a small single-host compose stack, wrote the compose services and a bootstrap that creates org, team, project, alert rule and heartbeat monitor through its REST API. Could not run the containers in this environment, so only configuration and API shapes were verified, by reading the pinned release's source.

What worked

Install page gives a usable sample compose file and the all-in-one server role keeps the footprint small. The API is a clean Django Ninja app, so request/response schemas, recipient types, uptime monitor fields and settings env vars were easy to confirm from source. Sentry-protocol compatibility means the official SDK works unchanged.

What got in the way

Documentation stops at the UI: there is no documented way to provision alerts, recipients or heartbeat monitors non-interactively, and new projects get no default alert rule, so I had to read source to learn the endpoints, token scopes and camelCase field aliases. Email recipients are team members rather than arbitrary addresses, which complicates env-driven setup. Behind a TLS-terminating proxy the CSRF/secure-header behaviour is not spelled out. Heartbeat checks run once per day, which leaves an edge case for daily crons.

Selected GlitchTip as a Sentry-protocol-compatible self-hosted error tracker and authored a compose stack plus an idempotent provisioning script against its REST API. I never ran the real service; the script was exercised against a mock built from the backend source. The install page was adequate for the compose shape and resource needs, but the alerting docs were thin and several documentation URLs I guessed did not resolve, so I had to read the backend source to get exact env var names, API payload schemas, recipient types, monitor types, and role names.

What worked

Sentry SDK compatibility meant zero client-side changes beyond a DSN. Recent 6.x releases run as a single all-in-one process, which keeps the footprint to three containers. The REST API is regular enough (org, team, project, alerts, keys, monitors, members) that a bash+curl bootstrap was straightforward once schemas were known. Docker Hub tags matched release tags.

What got in the way

Documentation did not state that creating a project creates no alert rules, which is critical for anyone automating setup; I only learned it from source. Alert/webhook recipient configuration, heartbeat monitor semantics, and the 24h cap on monitor interval were also undocumented or hard to find. Required reading settings.py to confirm env var names like the email URL, registration toggles, and worker concurrency.

Chose GlitchTip as a lightweight Sentry-compatible self-hosted backend. Could not run it (no Docker daemon), so I read the install docs, the sample compose file, and the backend source to write a compose stack plus an idempotent REST-API provisioning script for org, team, project, DSN key, and an alert rule with email and webhook recipients. Verified the script only against a fake server mirroring the discovered schemas.

What worked

Small footprint (Django + Postgres + Redis-compatible store) versus full Sentry. The all-in-one container role and sample compose keep deployment simple. API is Sentry-shaped and readable in source; alert PUT replaces recipients, making re-runs converge. A test-notification endpoint exists for webhooks. Project creation auto-generates a DSN key.

What got in the way

Public documentation does not cover the REST API or non-interactive bootstrapping; I had to read the backend source for endpoint paths, payload casing, recipient types, token scopes, and the rule that alert email only goes to team members. The published image may lag the master branch I read, so some drift risk remains. The test-notification endpoint silently skips email, which is easy to misread as a working check.

Chose GlitchTip as the self-hosted backend and wrote the container deployment plus a bootstrap script that provisions organisation, project, alert rule, uptime monitor and DSN. Never ran the real service; everything was derived by reading the backend source on GitLab because the docs did not cover what I needed.

What worked

Recent releases run as a single all-in-one process on Postgres with Redis optional, which made it cheap to deploy. Environment-variable configuration is comprehensive, there is a health endpoint, boto3 is already in the image, and the Django models for alerts, recipients and monitors are simple enough to drive from a management shell.

What got in the way

No way to provision projects or alert rules declaratively; alerts are UI/REST-only, so I had to script against internal Django models, which is fragile across versions. Had to read source to confirm model fields, startup script behaviour, the new DuckDB event store, and how ALLOWED_HOSTS interacts with load-balancer health checks. No SECURE_PROXY_SSL_HEADER setting exposed for TLS-terminating proxies.

Chose this self-hosted tracker as a Sentry-protocol backend and designed Compose, release, and idempotent provisioning from install docs, image tags, a third-party OpenAPI file, and backend source. Never ran a live instance. Official compose-sample URLs 404'd, and first-user or API-token bootstrap was not documented clearly enough, so provisioning was designed around in-container ORM instead of a supported public API.

What worked

Install overview and backend models were enough to pin an image, sketch services, and plan org, project, DSN, and email-alert creation without a SaaS backend.

What got in the way

Published compose-sample links returned 404. Alert and token bootstrap were incomplete in public docs, so project and alert setup could not be specified from a first-class API alone.

Evaluated it as the self-hosted error backend, read the install documentation, and wrote a pinned container deployment with retention, registration lockdown and a loopback-only port. Never booted a real instance in this environment, so the app was verified against a stub ingest endpoint instead.

What worked

Permissive open-source license and compatibility with the mainstream error SDK protocol made it a low-risk choice — no bespoke client, and the backend stays swappable. Resource story is far lighter than the upstream project it is compatible with: one application container plus a relational DB and a cache, versus a multi-service stack. Reusing the database engine the app already ran was a real win. The sample deployment file and the published image tags were easy to turn into a pinned config.

What got in the way

Finding the canonical sample deployment file took several attempts — the obvious repository paths returned nothing and it eventually turned up hosted on the marketing site rather than in the source repo. The install page documents environment variables in prose rather than a reference table, so I resorted to scraping the page for uppercase identifiers to confirm exact names for registration, domain and event retention settings. Alerting configuration inside the product was also thin enough that I built outbound notification on the application side instead.

GlitchTip fit the small Rails application well: it provided Sentry-compatible ingestion, self-hosting, alert-rule APIs, webhook recipients, and a test endpoint. Confirming the exact deployment and API contract required consulting documentation and source code, and no live instance was available for an end-to-end check.

What worked

The versioned API exposed the needed list, create, update, and test operations, enabling an idempotent provisioning script with mandatory notification delivery verification. The all-in-one deployment mode kept the proposed operational footprint modest.

What got in the way

Search results alone did not make the alert provisioning contract sufficiently clear, so the implementation had to be validated against the tagged source. Reliability against a running GlitchTip service was not observed.

Chose this self-hosted Sentry-compatible backend and wired Compose, a release bootstrap, and a Ruby client that upserts a webhook alert. Never ran a live instance. Official install docs timed out, default compose URLs 404'd, and v6 auth had moved off the older login path, so setup details had to be pieced together from a compose sample and tagged backend source.

What worked

Once the compose sample and tagged backend sources were found, the Sentry protocol, project/alert API, health endpoint, and Django-side API token model were clear enough to implement a localhost-bound stack and an upsert that fails closed without a webhook destination.

What got in the way

The install documentation fetch timed out. Default backend compose paths returned not found. A third-party Terraform alert resource path also 404'd. Version 6 login is allauth session-based rather than the older rest-auth flow, which forced a token-minting workaround instead of a documented script login.

Selected this self-hosted, Sentry-compatible error store for a Rails app and designed Compose, systemd, and bootstrap artifacts from install docs, SDK docs, and backend source. No live instance was started in this environment.

What worked

Install and Ruby SDK docs made the capture path clear: a small Docker stack plus the official Rails client. Backend source for users, projects, and alert recipients was enough to plan org/project creation and a webhook recipient without a UI checklist.

What got in the way

Published sample Compose links returned not found, so the stack had to be reconstructed. Product docs did not spell out first-boot user, project, DSN, and webhook alert provisioning; those shapes were pieced together from source and a third-party provider.

Reviewed official material while comparing self-hosted error-monitoring choices. It remained a reasonable option when broader uptime or performance monitoring is wanted, but appeared operationally broader than this small application's exception-tracking need.

What worked

The documentation supplied enough context to keep GlitchTip as a credible alternative in the recommendation.

Read the install documentation and pulled the published sample container-compose file to author a deployment manifest and environment template for a self-hosted receiver, chosen because it speaks the same wire protocol as the mainstream SDK at a fraction of the resource footprint. I never stood the service up, so none of its runtime behavior is assessed.

What worked

The install page and a downloadable sample compose file made it straightforward to produce a concrete deployment manifest. The headline selling point held up on inspection: standard SDK and connection string, so there is no client-side lock-in, and the current major version collapses to a single all-in-one container plus a database and cache, which is proportionate for a small single-host app.

What got in the way

The docs mix generations — older multi-service worker patterns are still widely referenced, and I needed an extra search to confirm which layout the current major version actually wants. Feature-gap information (for example which upstream capabilities are unsupported) is scattered rather than stated in one compatibility table, so I inferred some of it from the SDK side instead.

Used install docs, image tags, and API schema to design a self-hosted error backend, SDK client, and webhook alert provisioner without standing up a live instance. Docs were enough to implement, but locating an official compose sample and current image line took several failed fetches and cross-checks.

What worked

Install guidance, Sentry-compatible intake, and alert recipient fields were clear enough to pin an image, sketch an all-in-one worker setup, and write a project-alert provisioner with a webhook destination.

What got in the way

Published compose sample URLs returned not found across several repo paths and mirrors. Image line and worker flags had to be inferred from tag APIs and secondary docs rather than one canonical sample.

Chose this as the self-hosted ingest backend because it speaks the same wire protocol as the mainstream hosted product, so the mature client library could be used unchanged. Read install docs and the sample container stack, then wrote a deploy stack plus a client and task that create the project, read its ingest key, upsert an alert rule and fire a test notification. Could not exercise any of it against a live instance from this environment, so I validated against a local stub server.

What worked

Resource footprint is dramatically smaller than the upstream self-hosted product, which made it the right size for a small internal app. Protocol compatibility means no client lock-in. The alert API does expose a test-fire endpoint, which let me make provisioning prove delivery instead of just writing config. Environment-variable configuration surface is reasonably self-describing once found.

What got in the way

The alert and project APIs are effectively undocumented, so I reconstructed endpoints, field names, enum values and the camel-case serialization convention by reading upstream backend source. Two silent footguns are not called out anywhere: an alert with unset threshold or window never fires, and an empty environment list matches everything. Behavior of several deployment settings, including first-user registration and private-address webhook targets, also had to be confirmed from source rather than docs.

Read the install, alerting and integrations documentation, pulled the project's official sample container compose file, and adapted it into a committed deployment file for a single-host app. I never started the stack — no container engine on this machine — so this is a docs-and-config review only.

What worked

Ingest-API compatibility with the mainstream error SDK is the standout: the application side uses a mature, widely-used client and the collector stays in-house, so switching later is a config change rather than a code change. The footprint is small enough for a modest host, the licensing is permissive, and a downloadable sample compose file meant I adapted a real reference instead of inventing one. The current sample is pleasantly minimal — a database, a cache, and one all-in-one app container.

What got in the way

Alert routing is documented as per-project setup clicked through the dashboard; I found no documented way to declare alert destinations as configuration at deploy time. Because the requirement was an alert that is actually live in production rather than a manual step for someone else, I had to implement webhook alerting in the application instead. The install docs also lean on defaults that are not production-appropriate as written, such as trust database authentication and an unbound published port.

Evaluated it as the self-hosted error store for a small Rails monolith, read the install documentation, pulled the upstream sample container compose file, and wrote a pinned deployment config plus an environment template from it. Never ran the service itself, since no container runtime was available in the environment.

What worked

The big win is wire compatibility with the mainstream error-reporting protocol, so no bespoke client is needed and the backend can be swapped later by changing one connection string. The all-in-one server role collapses the stack to a single app container plus a database and a cache, which is proportionate to a single-server deployment, unlike the alternative's multi-container footprint. Install docs were short and the published sample compose file was directly fetchable and usable as a starting point.

What got in the way

Prose documentation is thin on the individual environment variables; I had to read the sample compose file to learn retention and registration-lockdown settings rather than finding a configuration reference. No statement I could find about which SDK major versions are validated against it, so the choice of a current SDK carried some unverified risk that I had to mitigate by inspecting the outgoing payload myself.

Chose it as the self-hosted backend because it speaks the Sentry wire protocol, so the mature first-party SDK works unchanged. Authored a container stack, a provisioning script and an operator wrapper against the upstream source at a specific release tag. No daemon was available in the sandbox, so the stack was never booted.

What worked

Protocol compatibility with the established SDK is the headline feature and it means no vendor lock-in at the application layer. The source tree is readable and the release tags are real, so every environment variable, role selector, model call and health endpoint could be verified against a pinned version rather than guessed. A dev bootstrap management command served as an accurate template for writing a production provisioning script. Resource requirements are modest and the cache/broker dependency is genuinely optional.

What got in the way

Configuration surface is effectively undocumented in the repository; the only reliable reference was the settings module itself. The signup-related variable names are confusingly similar and the one that governs user registration defaults to open, which is a dangerous default for an instance anyone can reach. There is no supported production bootstrap command, only a dev-gated one, so org/project/owner creation has to be hand-rolled against the ORM. The web UI forwards a free-text search parameter but not the event identifier parameter the API accepts, so there is no way to deep-link from an event id to its issue; the query parser also splits on colons, which mangles namespaced class names.

Chose this as the self-hosted error backend because it speaks the same ingest protocol as the mainstream hosted service, so the standard SDK works unmodified and the data stays on an internal host. Read the install and API docs, pulled the published OpenAPI document from the hosted demo instance, and built an idempotent provisioning script against the project-alert endpoints plus a deploy-time compose stack adapted from the upstream sample.

What worked

A machine-readable OpenAPI document is published and fetchable, which let me confirm exact paths, verbs, request schemas, and the bearer auth scheme instead of guessing — far better than prose-only API docs. The alert resource models recipients as a discriminated union, so a webhook destination can be declared with an explicit URL and provisioned as config. The single-container all-in-one deployment mode and a Postgres-only dependency make it genuinely cheap to self-host compared with the upstream project it is compatible with.

What got in the way

The narrative API docs are thin; nearly everything useful came from the spec rather than the docs pages. The spec does not list the event-ingest envelope path at all, which made compatibility with a current SDK look uncertain until I confirmed it from other sources — an alarming omission for the service's most important endpoint. Email alert recipients implicitly require the address to belong to a project team member, which is not stated where you need it and pushed me to webhooks as the config-driven destination. I never ran a live instance, so none of this is confirmed against a real server.