Reduce Sentry spend by 60-95% through SDK-level sampling, server-side inbound filters, beforeSend event dropping, and quota management — without losing visibility into production errors that matter.
Prerequisites
Active Sentry account with org:read and project:read scopes on an auth token
Access to the project's Sentry.init() configuration (typically sentry.client.config.ts or instrument.ts)
Current plan tier identified: Developer (free, 5K errors/mo), Team ($26/mo, 50K errors + 100K transactions), or Business ($80/mo, 100K errors + 500K transactions)
SENTRY_AUTH_TOKEN and SENTRY_ORG environment variables set for API calls
@sentry/node >= 8.0 or @sentry/browser >= 8.0 installed
Instructions
Step 1 — Audit Current Usage via the Stats API
Query the Sentry Usage Stats API to understand where volume comes from before making changes. This endpoint returns event counts grouped by category over any time period.
# Pull 30-day usage breakdown by category
curl -s -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
"https://sentry.io/api/0/organizations/$SENTRY_ORG/stats/usage/?statsPeriod=30d&groupBy=category&field=sum(quantity)&interval=1d" \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
print('=== 30-Day Usage by Category ===')
for group in data.get('groups', []):
cat = group['by']['category']
total = sum(interval[1] for interval in group.get('series', {}).get('sum(quantity)', []))
print(f' {cat}: {total:,} events')
"
# Identify top error-producing projects
curl -s -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
"https://sentry.io/api/0/organizations/$SENTRY_ORG/stats/usage/?statsPeriod=30d&groupBy=project&category=error&field=sum(quantity)" \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
projects = []
for group in data.get('groups', []):
proj = group['by']['project']
total = sum(interval[1] for interval in group.get('series', {}).get('sum(quantity)', []))
projects.append((proj, total))
projects.sort(key=lambda x: -x[1])
print('=== Top Error-Producing Projects ===')
for name, count in projects[:10]:
print(f' {name}: {count:,}')
"
Record the baseline numbers. You need these to measure savings after optimization.
Step 2 — Configure Error Sampling with sampleRate
The sampleRate option in Sentry.init() controls the percentage of error events sent to Sentry. Setting it to 0.1 means only 10% of errors are sent, yielding a 90% cost reduction on the error category.
import * asSentryfrom'@sentry/node';
Sentry.init({
dsn: process.env.SENTRY_DSN,
// 10% of errors sent = 90% cost reduction// Sentry extrapolates counts in the Issues dashboardsampleRate: 0.1,
});
Trade-off: Low-frequency errors (< 10 occurrences/day) may be missed entirely. Mitigate this by using beforeSend to always send errors with specific severity or tags rather than relying on blanket sampling.
Step 3 — Configure Performance Sampling with tracesSampleRate and tracesSampler
Performance monitoring (transactions/spans) is typically the largest cost driver. A tracesSampleRate of 0.05 sends only 5% of traces, cutting performance costs by 95%.
import * asSentryfrom'@sentry/node';
Sentry.init({
dsn: process.env.SENTRY_DSN,
// Static: 5% of all traces (95% cost reduction)tracesSampleRate: 0.05,
// Dynamic: per-endpoint sampling for fine-grained control// When tracesSampler is defined, it overrides tracesSampleRatetracesSampler: (samplingContext) => {
const { name, attributes } = samplingContext;
// Never trace health checks, readiness probes, static assetsif (name?.match(/\/(health|healthz|ready|livez|ping|robots\.txt|favicon)/)) {
return0;
}
if (name?.match(/\.(js|css|png|jpg|svg|woff2?|ico)$/)) {
return0;
}
// High-value: payment and auth flows get 50% samplingif (name?.includes('/checkout') || name?.includes('/payment')) {
return0.5;
}
if (name?.includes('/auth') || name?.includes('/login')) {
return0.25;
}
// API routes: 5%if (name?.includes('/api/')) {
return0.05;
}
// Everything else: 1%return0.01;
},
});
The tracesSampler function receives a samplingContext with the transaction name (usually the route) and attributes. Return a number between 0 (drop) and 1 (always send), or true/false.
Step 4 — Drop Noisy Events with beforeSend
The beforeSend hook fires for every error event before it is sent to Sentry. Returning null drops the event entirely — it never counts against quota.
import * asSentryfrom'@sentry/node';
Sentry.init({
dsn: process.env.SENTRY_DSN,
beforeSend(event, hint) {
const error = hint?.originalException;
const message = typeof error === 'string' ? error : error?.message || '';
// Drop ResizeObserver noise (Chrome fires this constantly, never actionable)if (message.includes('ResizeObserver loop')) returnnull;
// Drop network errors from flaky client connectionsif (/^(Failed to fetch|NetworkError|Load failed|AbortError)$/i.test(message)) {
returnnull;
}
// Drop cancelled navigation (user clicked away)if (message.includes('cancelled') || message.includes('AbortError')) {
returnnull;
}
// Drop browser extension errors by checking stack framesconst frames = event.exception?.values?.[0]?.stacktrace?.frames || [];
if (frames.some(f => f.filename?.match(/extensions?\//i) || f.filename?.match(/^(chrome|moz)-extension:\/\//))) {
returnnull;
}
// Always send critical errors regardless of sampleRate// Re-enable any that were sampled outif (event.level === 'fatal' || event.tags?.critical === 'true') {
return event;
}
return event;
},
// Complementary: block errors from known noisy patternsignoreErrors: [
'ResizeObserver loop completed with undelivered notifications',
'ResizeObserver loop limit exceeded',
'Non-Error promise rejection captured',
/Loading chunk \d+ failed/,
/Unexpected token '<'/, // HTML returned instead of JS (CDN issue)/^Script error\.?$/, // Cross-origin script with no details
],
// Block events from third-party scriptsdenyUrls: [
/extensions\//i,
/^chrome:\/\//i,
/^chrome-extension:\/\//i,
/^moz-extension:\/\//i,
/hotjar\.com/,
/intercom\.io/,
/google-analytics\.com/,
/googletagmanager\.com/,
/cdn\.segment\.com/,
],
});
Step 5 — Enable Server-Side Inbound Data Filters (Free)
Inbound data filters drop events at Sentry's edge before they are ingested and counted against quota. They cost nothing to enable.
Navigate to Project Settings > Inbound Filters (or use the API) and enable:
Filter
What it drops
Impact
Browser Extensions
Errors from Chrome/Firefox extensions
5-15% of frontend errors
Legacy Browsers
IE 11, old Safari/Chrome versions
2-10% depending on audience
Localhost Events
Errors from localhost and 127.0.0.1
Dev noise (variable)
Web Crawlers
Bot-triggered errors (Googlebot, Bingbot)
1-5% of frontend errors
Filtered Transactions
Health checks, static asset requests
10-40% of transactions
# Enable inbound filters via APIfor filter in browser-extensions legacy-browsers localhost-events web-crawlers; do
curl -s -X PUT \
-H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-H "Content-Type: application/json" \
-d '{"active": true}' \
"https://sentry.io/api/0/projects/$SENTRY_ORG/$SENTRY_PROJECT/filters/$filter/"echo" -> Enabled: $filter"done
Add custom error message filters for project-specific noise:
Step 6 — Configure Spike Protection and Per-Key Rate Limits
Spike protection is auto-enabled on all Sentry plans and caps burst events during sudden spikes (deploy bugs, infinite loops). Verify it is active under Organization Settings > Spike Protection.
Per-key rate limits restrict events per DSN key per time window. Set these in Project Settings > Client Keys (DSN) > Rate Limiting or via the API:
# Set rate limit: 1000 errors per hour per DSN key
curl -s -X PUT \
-H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-H "Content-Type: application/json" \
-d '{"rateLimit": {"window": 3600, "count": 1000}}' \
"https://sentry.io/api/0/projects/$SENTRY_ORG/$SENTRY_PROJECT/keys/$KEY_ID/"
Spend allocations (Team and Business plans): Set per-category budgets under Settings > Subscription > Spend Allocations to cap on-demand spending per billing period.
Step 7 — Optimize Reserved vs On-Demand Volume
Sentry offers two pricing models for volume above the plan's included quota:
Model
Rate (errors)
Best for
Reserved volume
~$0.000180/event (pre-paid blocks)
Predictable workloads
On-demand volume
~$0.000290/event (pay-as-you-go)
Spiky/seasonal traffic
Reserved volume is approximately 38% cheaper per event than on-demand. If your 30-day audit shows consistent volume, purchase reserved blocks to match the P90 usage. Let spikes overflow into on-demand.
Example calculation:
Average monthly errors: 120,000
Plan included: 50,000 (Team plan)
Overage: 70,000
On-demand cost: 70,000 x $0.000290 = $20.30/month
Reserved cost: 70,000 x $0.000180 = $12.60/month
Monthly savings: $7.70 ($92.40/year)
Step 8 — Reduce Event Payload Size
Smaller payloads mean lower bandwidth costs and faster event processing. These settings do not reduce event count but lower overall resource consumption.
After deploying changes, wait 48-72 hours and re-run the usage audit from Step 1 to measure actual savings.
# Compare current period vs previous period
curl -s -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
"https://sentry.io/api/0/organizations/$SENTRY_ORG/stats/usage/?statsPeriod=7d&groupBy=category&field=sum(quantity)&interval=1d" \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
print('=== Post-Optimization 7-Day Usage ===')
for group in data.get('groups', []):
cat = group['by']['category']
total = sum(interval[1] for interval in group.get('series', {}).get('sum(quantity)', []))
print(f' {cat}: {total:,} events')
print()
print('Compare against your Step 1 baseline to calculate % reduction.')
"
Output
After completing this skill:
SDK sampling configured: sampleRate for errors, tracesSampler for performance traces
