sentry-cost-tuning
Optimize Sentry spend through intelligent sampling and filtering without losing critical production visibility.
Install
mkdir -p .claude/skills/sentry-cost-tuning && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3377" && unzip -o skill.zip -d .claude/skills/sentry-cost-tuning && rm skill.zipInstalls to .claude/skills/sentry-cost-tuning
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Optimize Sentry costs, reduce event volume, and manage quota spend.Key capabilities
- →Audit current Sentry usage via the Stats API
- →Configure error sampling with sampleRate
- →Configure performance sampling with tracesSampleRate and tracesSampler
- →Drop noisy events with beforeSend
- →Enable server-side inbound filters
How it works
The skill reduces Sentry spend by applying SDK-level sampling for errors and performance traces, dropping noisy events with `beforeSend` hooks, and enabling server-side inbound filters.
Inputs & outputs
When to use sentry-cost-tuning
- →Reducing Sentry monthly billing
- →Implementing client-side event sampling
- →Auditing Sentry event volume by category
- →Configuring beforeSend for noise reduction
About this skill
Sentry Cost Tuning
Overview
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:readandproject:readscopes on an auth token - Access to the project's
Sentry.init()configuration (typicallysentry.client.config.tsorinstrument.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_TOKENandSENTRY_ORGenvironment 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 * as Sentry from '@sentry/node';
Sentry.init({
dsn: process.env.SENTRY_DSN,
// 10% of errors sent = 90% cost reduction
// Sentry extrapolates counts in the Issues dashboard
sampleRate: 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 * as Sentry from '@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 tracesSampleRate
tracesSampler: (samplingContext) => {
const { name, attributes } = samplingContext;
// Never trace health checks, readiness probes, static assets
if (name?.match(/\/(health|healthz|ready|livez|ping|robots\.txt|favicon)/)) {
return 0;
}
if (name?.match(/\.(js|css|png|jpg|svg|woff2?|ico)$/)) {
return 0;
}
// High-value: payment and auth flows get 50% sampling
if (name?.includes('/checkout') || name?.includes('/payment')) {
return 0.5;
}
if (name?.includes('/auth') || name?.includes('/login')) {
return 0.25;
}
// API routes: 5%
if (name?.includes('/api/')) {
return 0.05;
}
// Everything else: 1%
return 0.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 * as Sentry from '@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')) return null;
// Drop network errors from flaky client connections
if (/^(Failed to fetch|NetworkError|Load failed|AbortError)$/i.test(message)) {
return null;
}
// Drop cancelled navigation (user clicked away)
if (message.includes('cancelled') || message.includes('AbortError')) {
return null;
}
// Drop browser extension errors by checking stack frames
const frames = event.exception?.values?.[0]?.stacktrace?.frames || [];
if (frames.some(f => f.filename?.match(/extensions?\//i) || f.filename?.match(/^(chrome|moz)-extension:\/\//))) {
return null;
}
// Always send critical errors regardless of sampleRate
// Re-enable any that were sampled out
if (event.level === 'fatal' || event.tags?.critical === 'true') {
return event;
}
return event;
},
// Complementary: block errors from known noisy patterns
ignoreErrors: [
'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 scripts
denyUrls: [
/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 API
for 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:
# Add custom inbound filter for error messages
curl -s -X PUT \
-H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-H "Content-Type: application/json" \
-d '{"active": true, "subfilters": ["ResizeObserver", "ChunkLoadError", "Script error"]}' \
"https://sentry.io/api/0/projects/$SENTRY_ORG/$SENTRY_PROJECT/filters/custom-error-messages/"
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
---
*Content truncated.*
When not to use it
- →When low-frequency errors (< 10 occurrences/day) must not be missed
- →When complex dynamic query builder logic requires manual tracing
Prerequisites
Limitations
- →Low-frequency errors (< 10 occurrences/day) may be missed entirely with blanket sampling
- →Cannot analyze compiled/minified code for Sentry configuration
- →False positives may occur on sanitized input if not recognized
How it compares
This skill provides specific code examples and API calls for Sentry cost optimization, unlike general advice on reducing event volume.
Compared to similar skills
sentry-cost-tuning side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| sentry-cost-tuning (this skill) | 1 | 27d | Caution | Intermediate |
| langfuse | 7 | 6mo | No flags | Intermediate |
| instantly-observability | 2 | 27d | Caution | Intermediate |
| error-tracking | 1 | 9mo | Caution | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
langfuse
davila7
Expert in Langfuse - the open-source LLM observability platform. Covers tracing, prompt management, evaluation, datasets, and integration with LangChain, LlamaIndex, and OpenAI. Essential for debugging, monitoring, and improving LLM applications in production. Use when: langfuse, llm observability, llm tracing, prompt management, llm evaluation.
instantly-observability
jeremylongshore
Set up comprehensive observability for Instantly integrations with metrics, traces, and alerts. Use when implementing monitoring for Instantly operations, setting up dashboards, or configuring alerting for Instantly integration health. Trigger with phrases like "instantly monitoring", "instantly metrics", "instantly observability", "monitor instantly", "instantly alerts", "instantly tracing".
error-tracking
diet103
Add Sentry v8 error tracking and performance monitoring to your project services. Use this skill when adding error handling, creating new controllers, instrumenting cron jobs, or tracking database performance. ALL ERRORS MUST BE CAPTURED TO SENTRY - no exceptions.
azure-monitor-opentelemetry-ts
microsoft
Instrument applications with Azure Monitor and OpenTelemetry for JavaScript (@azure/monitor-opentelemetry). Use when adding distributed tracing, metrics, and logs to Node.js applications with Application Insights.
genkit-production-expert
jeremylongshore
Build production Firebase Genkit applications including RAG systems, multi-step flows, and tool calling for Node.js/Python/Go. Deploy to Firebase Functions or Cloud Run with AI monitoring. Use when asked to "create genkit flow" or "implement RAG". Trigger with relevant phrases based on skill purpose.
logging-best-practices
neondatabase
Logging best practices focused on wide events (canonical log lines) for powerful debugging and analytics