Scale Sentry for high-traffic applications handling millions of events per day.
Use when optimizing SDK performance at high volume, implementing adaptive sampling,
managing quotas and costs at scale, or deploying Sentry across multi-region infrastructure.
Trigger with phrases like "sentry high traffic", "scale sentry", "sentry millions events",
"sentry high volume", "sentry quota management", "sentry load test".
Scale Sentry for high-traffic applications handling millions of events per day.
Use when optimizing SDK performance at high volume, implementing adaptive sampling,
managing quotas and costs at scale, or deploying Sentry across multi-region infrastructure.
Trigger with phrases like "sentry high traffic", "scale sentry", "sentry millions events",
"sentry high volume", "sentry quota management", "sentry load test".
Designed for Claude Code, also compatible with Codex and OpenClaw
Sentry Load & Scale
Overview
Configure Sentry for applications processing 1M+ requests/day without sacrificing error visibility, burning through quota, or adding measurable SDK overhead. Covers adaptive sampling, connection pooling, multi-region tagging, quota management, SDK benchmarking, batch submission, load testing, and self-hosted deployment considerations.
Prerequisites
Application handling sustained high traffic (>10K requests/min or >1M events/day)
Sentry organization with quota and billing access (Settings > Subscription)
@sentry/node v8+ installed (npm ls @sentry/node)
Performance baseline established (p50/p95/p99 latency without Sentry)
Event volume estimates calculated per category (errors, transactions, replays, attachments)
Instructions
Step 1 — Implement Adaptive Sampling
Static tracesSampleRate wastes quota at scale because it treats a health check the same as a checkout. Replace it with a traffic-aware tracesSampler that adjusts rates based on endpoint criticality and current load.
At high throughput, every byte and every millisecond of SDK processing matters. This configuration reduces memory footprint, payload size, and CPU time.
Kafka: KAFKA_NUM_PARTITIONS: 32 (match to consumer count)
Snuba: 4+ consumer replicas for Clickhouse ingestion parallelism
Clickhouse: 16G+ RAM, dedicated SSD volumes
Self-hosted vs SaaS break-even:
SaaS at 100M events/month: ~$2,500/mo (Business plan + overage)
Self-hosted (3x r6g.2xlarge): ~$1,200/mo infra + $800/mo ops (0.25 FTE)
Break-even: ~50M events/month
→ Use SaaS up to 50M events; evaluate self-hosted above that
Output
Adaptive sampling reducing duplicate error volume by 90%+ while preserving first-occurrence fidelity
Traffic-aware tracesSampler with 5 tiers adjusting dynamically based on endpoint volume
SDK memory and CPU footprint minimized (15 breadcrumbs, truncated contexts, filtered headers)
Connection pooling via persistent HTTPS agent for efficient event submission
Multi-region infrastructure tags for filtering by region/cluster/pod in Sentry dashboard
Cost model with reserved volume pricing showing $106/month for 10M requests/day
k6 load test script validating Sentry overhead stays under 5ms at p95
Batch job processing pattern with scope isolation and periodic flush
Self-hosted vs SaaS break-even analysis for enterprise decision-making
Error Handling
Error
Cause
Solution
Events silently dropped
SDK buffer full during traffic spike
Increase transportOptions.bufferSize to 200+, verify network to Sentry ingest
429 rate limit from Sentry
Quota exhausted or spike protection triggered
Enable spike protection in Settings > Subscription, reduce sample rates
Memory growing linearly over time
Breadcrumb or scope accumulation
Reduce maxBreadcrumbs, verify withScope is used (not configureScope)