getsentry/sentry
Developer-first error tracking and performance monitoring
13 hidden assumptions · 6-stage pipeline · 8 components
Like any codebase, this fullstack makes assumptions it never checks — most are routine. The ones worth your attention are below.
Captures errors and performance data from applications and provides debugging workflows
Data enters Sentry through SDK HTTP requests containing error events or performance traces. The EventManager validates and enriches this data, uses GroupingEnhancer rules to normalize stacktraces, then applies grouping logic to either create new issues or update existing ones. The processed events are stored in PostgreSQL/ClickHouse while the React frontend loads user configuration via /api/client-config/ and provides interfaces for browsing, triaging, and analyzing the collected data.
Under the hood, the system uses 3 feedback loops, 4 data pools, 4 control points to manage its runtime behavior.
A 8-component fullstack. 16895 files analyzed. Data flows through 6 distinct pipeline stages.
Hidden Assumptions
Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".
If the backend returns malformed JSON or missing required fields, the frontend crashes with a runtime error that's hard to debug
If another script overwrites window.__initialData or the browser doesn't support globals, the entire frontend loses its configuration data and becomes non-functional
Invalid references throw an Error during render, crashing the entire UI component tree without graceful fallback
Show everything (10 more)
The window.__initialData.initialTrace object exists and has sentry_trace and baggage properties when making preload requests
If this fails: If the trace data isn't available yet or was cleared, all preload requests fail with 'Cannot read property sentry_trace of undefined' causing silent data loading failures
static/app/bootstrap/index.tsx:promiseRequest
When author.type is 'user', the author.user field is always provided with valid AvatarUser data
If this fails: If user data is missing for type 'user', the avatar component receives undefined and renders blank or crashes, breaking activity feeds
static/app/components/activity/item/index.tsx:ActivityItem
API authentication headers and signatures will fit within standard HTTP header size limits (typically 8KB)
If this fails: Large organization contexts or complex authentication tokens could exceed server header limits, causing 431 Request Header Fields Too Large errors that appear as authentication failures
src/sentry/api/authentication.py
The aggregations array is pre-filtered to only contain function-type fields before being passed to ArithmeticBuilder
If this fails: If non-function aggregations are included, they get filtered out during context creation causing silently missing options in the UI
static/app/components/arithmeticBuilder/index.tsx:ArithmeticBuilder
The date prop, when provided as a string, is in a format that moment.js can parse correctly
If this fails: Invalid date strings result in 'Invalid date' being displayed in the UI without user-friendly error messages
static/app/components/activity/item/index.tsx:ActivityItem
The browser supports the fetch API with all required options (credentials, priority, headers)
If this fails: In older browsers without full fetch support, requests silently fail or ignore important options like credentials, causing authentication issues
static/app/bootstrap/index.tsx:promiseRequest
Organization slugs in URLs are always URL-safe and contain no special characters that could interfere with routing or permission checks
If this fails: Special characters in organization slugs could cause routing mismatches or bypass permission checks if the slug isn't properly escaped
src/sentry/api/bases/organization.py:OrganizationEndpoint
The csrfCookieName, superUserCookieName, and superUserCookieDomain are set before any subsequent API calls are made
If this fails: If API calls happen before these globals are set, CSRF protection fails and requests are rejected with 403 Forbidden
static/app/bootstrap/index.tsx:bootApplication
The Operator enum contains all mathematical operators that the parser will encounter
If this fails: If the parser generates operators not in the enum, TokenOperator construction fails causing expression parsing to break
static/app/components/arithmeticBuilder/token/index.tsx:TokenOperator
The window.__SENTRY_DEV_UI flag accurately indicates development mode and window.location.host contains a valid domain
If this fails: In development, if the flag is incorrect or hostname is malformed, customer domain detection fails causing routing issues
static/app/bootstrap/index.tsx:bootWithHydration
Open the standalone hidden-assumptions report for sentry →
How Data Flows Through the System
Data enters Sentry through SDK HTTP requests containing error events or performance traces. The EventManager validates and enriches this data, uses GroupingEnhancer rules to normalize stacktraces, then applies grouping logic to either create new issues or update existing ones. The processed events are stored in PostgreSQL/ClickHouse while the React frontend loads user configuration via /api/client-config/ and provides interfaces for browsing, triaging, and analyzing the collected data.
- SDK Event Ingestion — Client SDKs POST JSON payloads to /api/store/ endpoints containing error events, transactions, or performance spans with stacktraces, breadcrumbs, and context data [Raw Event Data]
- Event Validation and Enrichment — EventManager validates the incoming payload schema, applies rate limits, enriches with IP geolocation and user agent parsing, and extracts key metadata
- Stacktrace Enhancement — GroupingEnhancer applies configurable rules to normalize stacktrace frames — removing file paths, grouping similar functions, and standardizing error patterns [Raw Stacktrace → Enhanced Stacktrace]
- Issue Grouping — Grouping algorithm computes fingerprints from enhanced stacktraces and error details, then either matches to existing GroupHash or creates new issue group [Enhanced Stacktrace → GroupingResult]
- Frontend Configuration Loading — React app fetches /api/client-config/ to get user permissions, organization settings, feature flags, and CSRF tokens needed for authenticated requests
- Real-time Alert Processing — IncidentLogic evaluates incoming metrics against alert rule thresholds, creates IncidentUpdateValues when conditions are met, and manages incident state transitions [Metrics Data → IncidentUpdateValues]
Data Models
The data structures that flow between stages — the contracts that hold the system together.
static/app/bootstrap/index.tsxTypeScript interface with user: User, organizationUrl: string, features: FeatureSet, csrfCookieName: string, customerDomain: CustomerDomain
Loaded via /api/client-config/ on app start, stored in window.__initialData, and accessed throughout the React app lifecycle
static/app/components/activity/item/index.tsxReact component props with author: {type: ActivityAuthorType, user?: AvatarUser}, date: string | Date, interval?: number, children: ReactNode
Created for each activity event (comments, status changes, assignments) and rendered in chronological feeds
src/sentry/grouping/api.pydataclass with config: GroupingConfig, variants: dict[str, BaseVariant], hashes: list[str], grouphashes: list[GroupHash]
Computed when processing new events to determine which existing issue group they belong to based on stacktrace and error characteristics
src/sentry/incidents/utils/types.pydataclass with entity: str, subscription_id: str, values: SubscriptionUpdateValues, timestamp: datetime
Generated by Snuba subscription updates when alert rule thresholds are crossed, triggers incident creation or resolution
static/app/components/arithmeticBuilder/index.tsxTypeScript type representing parsed mathematical expressions with aggregations: string[], functionArguments: FunctionArgument[], references?: Set<string>
Built by users in the UI for custom metrics and dashboard widgets, validated and executed against Snuba data
System Behavior
How the system operates at runtime — where data accumulates, what loops, what waits, and what controls what.
Data Pools
PostgreSQL tables storing processed events, issues, user data, and organizational metadata with relationships
ClickHouse-based time-series storage for high-volume event data, metrics aggregation, and performance queries
Browser-side configuration and user context loaded once and cached in window.__initialData
Redis-backed job queue for asynchronous processing of notifications, data cleanup, and background operations
Feedback Loops
- Alert Rule Evaluation (polling, balancing) — Trigger: Snuba subscription receives new metric data points. Action: IncidentLogic compares values against alert rule thresholds and updates incident status. Exit: Metric returns to normal range or alert rule is disabled.
- Grouping Feedback Training (self-correction, reinforcing) — Trigger: Users merge or split issue groups manually. Action: System learns from user corrections to improve automatic grouping accuracy. Exit: Sufficient training data collected or grouping rules updated.
- Rate Limiting (backpressure, balancing) — Trigger: Event ingestion rate exceeds organization quotas. Action: ApiAuthentication applies exponential backoff and drops excess events. Exit: Rate drops below threshold or quota increases.
Delays
- Event Processing Latency (async-processing, ~100ms-2s) — Events appear in UI after validation, enrichment, and grouping complete
- Configuration Cache TTL (cache-ttl, ~5 minutes) — Frontend configuration changes take up to 5 minutes to reflect in user sessions
- Alert Evaluation Window (batch-window, ~1-10 minutes) — Alert notifications may be delayed by evaluation window to reduce noise
Control Points
- Feature Flags (feature-flag) — Controls: Which UI features and API endpoints are available to different organizations. Default: organization-specific
- Event Sampling Rate (rate-limit) — Controls: What percentage of events are processed vs dropped for performance. Default: configured per organization
- Grouping Configuration (architecture-switch) — Controls: How stacktraces are normalized and which events group together into issues. Default: rule-based with ML assistance
- Alert Sensitivity (threshold) — Controls: When incidents trigger based on error rates, performance thresholds, and custom metrics. Default: user-configurable per alert rule
Technology Stack
Web framework providing REST API endpoints, authentication, and request routing
Frontend framework for building the web UI with components for dashboards, issue details, and settings
Type system for frontend code providing static analysis and IDE support
Primary database for user data, organization settings, and normalized event metadata
Time-series database for high-volume raw event data and analytics queries
Task queue backend and caching layer for session data and rate limiting
Query layer that translates high-level filters into optimized ClickHouse queries
Distributed task queue for background jobs like notifications and data processing
JavaScript testing framework for frontend unit and integration tests
Fast Rust-based bundler for building and hot-reloading the React frontend
Key Components
- OrganizationEndpoint (adapter) — Base class for all organization-scoped API endpoints, handles organization resolution, permission checking, and context setup
src/sentry/api/bases/organization.py - EventManager (processor) — Central orchestrator for event ingestion — validates, enriches, groups, and stores error events and performance data from SDKs
src/sentry/event_manager.py - ArithmeticBuilder (factory) — React component that provides a UI for building mathematical expressions over metrics, used in dashboards and custom queries
static/app/components/arithmeticBuilder/index.tsx - ActivityItem (transformer) — Renders timeline entries for user actions, system events, and status changes across issues, releases, and incidents
static/app/components/activity/item/index.tsx - TokenParser (parser) — Tokenizes and parses mathematical expressions into structured tokens (operators, functions, literals, references) for query building
static/app/components/arithmeticBuilder/token/index.tsx - ApiAuthentication (validator) — Handles multiple authentication methods (API keys, tokens, sessions, system auth) and rate limiting for API requests
src/sentry/api/authentication.py - GroupingEnhancer (transformer) — Applies rules to modify stacktrace frames before grouping to improve issue deduplication accuracy
src/sentry/grouping/enhancer/__init__.py - IncidentLogic (orchestrator) — Manages alert rule evaluation, incident lifecycle (creation, escalation, resolution), and notification dispatching
src/sentry/incidents/logic.py
Explore the interactive analysis
See the full architecture map, data flow, and code patterns visualization.
Analyze on CodeSeaRelated Fullstack Repositories
Frequently Asked Questions
What is sentry used for?
Captures errors and performance data from applications and provides debugging workflows getsentry/sentry is a 8-component fullstack written in Python. Data flows through 6 distinct pipeline stages. The codebase contains 16895 files.
How is sentry architected?
sentry is organized into 5 architecture layers: Frontend UI, API Layer, Event Processing, Storage & Analytics, and 1 more. Data flows through 6 distinct pipeline stages. This layered structure keeps concerns separated and modules independent.
How does data flow through sentry?
Data moves through 6 stages: SDK Event Ingestion → Event Validation and Enrichment → Stacktrace Enhancement → Issue Grouping → Frontend Configuration Loading → .... Data enters Sentry through SDK HTTP requests containing error events or performance traces. The EventManager validates and enriches this data, uses GroupingEnhancer rules to normalize stacktraces, then applies grouping logic to either create new issues or update existing ones. The processed events are stored in PostgreSQL/ClickHouse while the React frontend loads user configuration via /api/client-config/ and provides interfaces for browsing, triaging, and analyzing the collected data. This pipeline design reflects a complex multi-stage processing system.
What technologies does sentry use?
The core stack includes Django (Web framework providing REST API endpoints, authentication, and request routing), React (Frontend framework for building the web UI with components for dashboards, issue details, and settings), TypeScript (Type system for frontend code providing static analysis and IDE support), PostgreSQL (Primary database for user data, organization settings, and normalized event metadata), ClickHouse (Time-series database for high-volume raw event data and analytics queries), Redis (Task queue backend and caching layer for session data and rate limiting), and 4 more. This broad technology surface reflects a mature project with many integration points.
What system dynamics does sentry have?
sentry exhibits 4 data pools (Event Store, Analytics Store), 3 feedback loops, 4 control points, 3 delays. The feedback loops handle polling and self-correction. These runtime behaviors shape how the system responds to load, failures, and configuration changes.
What design patterns does sentry use?
4 design patterns detected: Multi-Tenant SaaS Architecture, Event Sourcing for Audit Trail, Plugin Architecture for Integrations, CQRS with Separate Read/Write Models.
Analyzed on April 20, 2026 by CodeSea. Written by Karolina Sarna.