Sentry

Sentry is an open-source debugging platform built for developers who need to detect, trace, and resolve errors and performance problems in production. It captures exceptions, crashes, and slow transactions in real time, groups them intelligently using fingerprinting and heuristic analysis, and surfaces the exact stack frame, request context, and user breadcrumbs that led to each failure. With SDKs available for every major language and runtime, Sentry slots into existing codebases without architectural changes.

Beyond error tracking, Sentry provides distributed tracing that follows a request across microservices, a performance monitoring suite that surfaces N+1 queries and slow database calls, session replay for watching exactly what a user did before encountering a bug, and uptime monitoring with alerting. The platform’s AI assistant, Seer, can automatically diagnose the root cause of an error and suggest or even apply a code fix directly through GitHub.

Sentry is built on Django and PostgreSQL for its control plane, with Kafka and Snuba (a ClickHouse query layer) powering the high-throughput event pipeline. It can handle millions of events per day in self-hosted configurations. The project is released under the Functional Source License, which permits internal use and self-hosting while restricting competing commercial offerings.

What You Get

• Real-time error and exception capture with full stack traces, local variable values, and request context for every event
• Distributed tracing that follows requests across services and highlights slow spans, N+1 queries, and external HTTP bottlenecks
• Session Replay — video-like recordings of user interactions replayed alongside the error timeline to reproduce hard-to-find bugs
• AI-powered Seer autofix that analyzes an error’s root cause and can open a GitHub pull request with a suggested fix
• Uptime monitoring with configurable alert rules and on-call routing via PagerDuty, Slack, email, and webhooks
• Performance Insights for frontend (Core Web Vitals, LCP/INP/CLS) and backend (database, cache, queue, HTTP trends) grouped by transaction name
• Cron job monitoring that alerts when scheduled tasks fail to start, run too long, or finish with errors
• Source maps and symbol server integration for deobfuscating minified JavaScript and native crash reports

Common Use Cases

• Production error triage — on-call engineers use Sentry’s alert rules and owner assignment to get paged for regressions, see exact stack traces, and resolve issues before users file support tickets
• Release quality gates — teams compare error rates between releases using Sentry’s release health dashboard to decide whether to roll back a deployment
• Frontend performance budgets — product teams track Core Web Vitals per page and transaction, catching regressions in LCP or INP before they affect SEO rankings
• Microservices debugging — platform engineers trace a slow API response across ten services using distributed traces to isolate which downstream call is the bottleneck
• AI-assisted bug fixing — developers trigger Seer autofix on a recurring crash and let it propose a fix as a pull request, reducing time-to-resolution from hours to minutes
• Background job observability — data teams monitor Celery and Sidekiq workers with Crons monitoring to catch silent failures in nightly ETL pipelines

Under The Hood

Architecture Sentry is structured as a modular monolith at its Django core but designed for horizontal decomposition through a formal silo model. The codebase distinguishes between a control silo (authentication, organization management, integrations) and region silos (event ingestion, issue grouping, performance data), allowing operators to run in a single monolith mode or split them across regions for data-residency compliance. The event ingestion path is event-driven: Relay (a Rust edge proxy) receives and normalizes events, emits them to Kafka, and multiple consumer workers process grouping, alerting, and storage asynchronously. The grouping subsystem is a layered strategy pipeline where fingerprinting rules, stack-trace enhancers, and machine-learning similarity checks feed a ClickHouse-backed hash store, ensuring duplicate events are deduplicated at scale without blocking the write path.

Tech Stack The backend is Python 3.12 with Django 5 and Django REST Framework serving the API. PostgreSQL handles relational data for projects, users, and issue metadata; ClickHouse (via the Snuba query service) stores the high-cardinality event and span data at columnar scale. Redis provides caching and rate limiting, while Kafka decouples ingest from processing. The frontend is a React and TypeScript single-page application bundled with rspack, using React Query for data fetching and a custom component library. Celery and a bespoke task-worker system handle background jobs. Session Replay uses a custom rrweb-based recording library. The Rust-written Relay proxy handles SDK-level filtering, PII scrubbing, and rate limiting before events even reach the Python layer.

Code Quality Sentry has an extensive and mature test suite with nearly three thousand Python test files, using pytest with factory-based fixtures and a broad set of integration tests against real database and Kafka connections. TypeScript strict mode is enforced throughout the frontend, and mypy covers the Python service layer. ESLint, Prettier, and Ruff enforce style automatically in CI. The codebase uses typed dataclasses and Protocol interfaces for dependency injection rather than monkeypatching, and CI runs on GitHub Actions with separate pipelines for unit tests, acceptance tests, and linting. Code comments are abundant and internal documentation includes architecture decision records in AGENTS.md and CLAUDE.md files.

What Makes It Unique Sentry’s combination of a pluggable, AI-augmented grouping engine and the Seer autofix service sets it apart from conventional error trackers. Rather than just showing a stack trace, Sentry’s grouping pipeline applies configurable fingerprinting rules, stack-trace enhancers, and an ML similarity index to prevent alert fatigue from noisy duplicate events. Seer goes further by reasoning over error context, relevant code history, and similar past fixes to generate a pull request — effectively closing the loop from detection to remediation without leaving the platform. The Relay edge layer, written in Rust for sub-millisecond overhead, also enables client-side PII scrubbing and event filtering before data ever leaves the user’s infrastructure, a capability most hosted competitors cannot match.

Self-Hosting

Sentry is released under the Functional Source License version 1.1 with an Apache 2.0 future license (FSL-1.1-Apache-2.0). This means you can freely run, modify, and deploy Sentry for your own internal use, for non-commercial research, or as part of professional services delivered to clients. The restriction is that you may not build a competing commercial product or SaaS offering on top of the Sentry codebase. Two years after each version is released, it automatically converts to the Apache 2.0 license, making it fully open source at that point. This is broadly permissive for the typical self-hoster but is worth reviewing with legal counsel if you intend to build a managed-monitoring service on top of it.

Running Sentry yourself is a substantial operational undertaking. The officially supported self-hosted deployment uses Docker Compose and requires a minimum of 4 CPU cores, 8 GB RAM, and 20 GB of fast disk — though production-grade installs with meaningful event volume need significantly more. The stack includes PostgreSQL, ClickHouse, Redis, Kafka, Zookeeper, and multiple Sentry worker processes (web, worker, cron, relay, snuba-consumers). Upgrades must be applied in release order because the migration chain is linear; skipping versions can break the database schema. You are responsible for all backups, scaling decisions, certificate rotation, and plugin/SDK version compatibility.

The hosted sentry.io service offers capabilities and guarantees that are difficult to replicate in self-hosted mode, including globally distributed Relay edge nodes for low-latency ingestion, managed ClickHouse clusters that scale automatically with event volume, and first-party access to Seer AI features (which make external API calls). The Business and Enterprise tiers add SSO via SAML2, audit logs, legal SLAs, and dedicated support channels. Self-hosters get community support through GitHub Discussions and Discord, and there is an active open-source community, but no SLA. For teams whose primary concern is data residency or air-gapped environments, self-hosting remains the right choice; for teams that want observability without infrastructure burden, the hosted tier is worth evaluating.