How do I stop error tracking costs from growing with traffic spikes?
Find what is multiplying events, then cut volume at three points: fix the root error, filter noise in the SDK with sampleRate, ignoreErrors and beforeSend, and drop leftovers at the server with inbound filters and rate limits. Also check what your tool meters. Per-event meters grow with traffic spikes; per-unique-issue meters do not.
Why it happens
Most error trackers bill on volume of one kind or another, so a bill jumps when the number of things you send jumps. The usual cause is not more users having more bugs. One error is thrown repeatedly: a loop that throws on every iteration, a retry that fails every second, a bot that hits a broken URL thousands of times, or a deploy that breaks a hot code path and multiplies the same event by every request. Sentry's own spike protection documentation describes the effect: because it bills on the number of events sent monthly, spikes can quickly consume a month's quota (docs.sentry.io, read 2026-11-13).
Errors are often not the biggest line. Performance tracing, session replay and profiling can each send far more data than errors, and they scale with traffic by default. In the Sentry SDK, tracesSampleRate defaults to nothing until you set it, and setting it to 1.0 sends every transaction. Replay has separate session and on-error sample rates. A sensible traffic-based rate for each is the lever, not one global switch.
So there are three questions: how many events does one root cause generate, how many of them do you actually need to see, and what does your tool count. The first is a bug, the second is configuration, and the third is a choice of vendor.
How to cap error tracking volume in any tool
Find what is multiplying events
Open the usage or stats view and sort issues by event count over the last day or week. A spike almost always traces to one or two issues with enormous counts, often first seen at one release. Note the release, the URL or the user agent. That tells you whether it is a bug, a bot or a deploy.
Fix the root error
One loop that throws ten thousand times is one bug. Fix it, or at least stop the retry from reporting every attempt. This is the only step that also improves your product, so do it first, then ship the fix and confirm the count drops in the release that contains it.
Sample and filter in the SDK
Sentry's JavaScript SDK documents sampleRate for error events, from 0.0 to 1.0 with a default of 1.0, picked at random (docs.sentry.io, read 2026-11-13). It documents ignoreErrors as a list of strings or regexes matching messages that are not sent, and denyUrls as patterns matched against the top stack frame's file URL, which is how you drop errors from browser extensions or third-party scripts. beforeSend can return null to skip an event. Set tracesSampleRate low for tracing.
Sentry.init({ dsn: "<your dsn>", sampleRate: 1.0, // keep all errors unless volume forces otherwise tracesSampleRate: 0.05, // tracing scales with traffic: sample it ignoreErrors: [/ResizeObserver loop/, "Non-Error promise rejection"], denyUrls: [/extensions\//i, /^chrome-extension:\/\//i], beforeSend(event) { return isNoise(event) ? null : event; }, });Dedupe repeated errors before they leave the process
A loop reporting the same error should report it once per interval. Keep a small in-memory map from error message plus top frame to the last time it was sent, and have beforeSend return null if the same key was sent in the last minute. This does not lose information: the first event carries the stack trace, and the rest add only a count.
const seen = new Map(); Sentry.init({ beforeSend(event) { const ex = event.exception?.values?.[0]; const key = ex?.type + "|" + ex?.value; const now = Date.now(); if (now - (seen.get(key) ?? 0) < 60_000) return null; seen.set(key, now); return event; }, });Add server-side filters and limits as a second net
SDK settings only protect services you have deployed. Server-side inbound filters drop events from known sources such as web crawlers, localhost, legacy browsers or a specific release before they count. Sentry's spike protection documentation also describes rate limits on DSN keys and release-based inbound filters as ways to manage a spike, and a spike protection feature that begins dropping events once a per-project threshold is reached (docs.sentry.io, read 2026-11-13). The same document notes that a sustained high volume becomes the new baseline, so it is a brake, not a fix.
Alert on volume before the bill does
Create an alert on event frequency per project or per issue, routed to chat. A rule that fires when a single issue exceeds a count in an hour catches a runaway loop in minutes instead of at the end of the month. Pair it with a quick release rollback procedure.
| Meter | What grows the bill | Effect of one looping error | What to ask the vendor |
|---|---|---|---|
| Events | Every captured event | Grows with every repeat | Is there a hard cap and what happens at the cap? |
| Unique issues (groups) | Distinct problems | Stays flat; it is one issue | Is there a fair-use ceiling on raw events? |
| Errors vs. transactions vs. replays | Each category separately | Tracing and replay can dwarf errors | Is each category sampled and capped separately? |
| Seats | Number of users | Not affected by volume | Does the price grow with team size? |
| Hosted data volume (GB) | Size of payloads, logs, attachments | Large events cost more | Is there size limit per event? |
A criteria table; no vendor prices or plan limits are quoted. Verify each answer on the vendor's pricing page.
When to use Bugsly
Bugsly meters unique issues, not events: a loop that throws the same error ten thousand times is one issue. Lower plans also carry a fair-use ceiling on raw events, so the meter is not unlimited volume; see /pricing for the current terms. Bugsly accepts events from Sentry's open SDKs, so the SDK options above (sampleRate, tracesSampleRate, ignoreErrors, denyUrls, beforeSend) work unchanged once you point the DSN at Bugsly.
On the server, Bugsly's inbound filters drop events from localhost, web crawlers, browser extensions, legacy browsers, message patterns and release patterns. Dropped events are not stored and are counted per reason for 24 hours. Frequency alerts can notify email, Slack, Telegram or a webhook. Your assistant can check consumption with the get_usage tool, which returns issues used against the issue limit, raw events used and the plan for an organization.
When Bugsly is not the right answer
If you need predictable pricing per event volume, for example to forecast cost from request counts, or you send high-volume tracing, compare tools that meter those directly rather than issues, and read each fair-use or sampling policy. Bugsly's issue-based meter is a good fit for error volume, but it does not remove the limits on tracing or replay volume.
If you want to self-host to control cost with your own hardware, Bugsly cannot be self-hosted. Open-source alternatives exist; see /compare and read each project's own documentation before relying on it.
Ask your AI assistant to do it
With the Bugsly MCP server connected (https://bugsly.dev/api/mcp; setup for ChatGPT, Claude, Cursor and Gemini CLI is on /mcp), paste this. The assistant reads first and reports back; you decide what happens next.
Assign to Bugsly: use get_usage for my organization to show issues used against the issue limit plus raw events, then list_issues sorted by event count and get_issue on the top three. Tell me which one is multiplying events, which release it started in and whether it looks like a loop, a bot or a bad deploy. Do not resolve or ignore anything; show me what you found so I can approve the next step.
Frequently asked questions
Why did my error tracking bill spike when my traffic did?
Usually one error is thrown on every request or retry, so event volume scales with traffic. Tracing and replay, if enabled at full rate, scale the same way.
Does sampling errors hide real bugs?
Sampling at 0.5 still catches a frequent bug, but it can miss a rare one. Prefer to filter known noise and dedupe repeats, and sample only if volume still demands it.
Which error tracking tool costs least for my traffic?
It depends on your event volume and on what the tool meters, so compare the meters in the table above and test with your real traffic. Check each vendor's own pricing page.
Can I turn off tracing but keep errors?
Yes. In the Sentry SDK tracing is off until you set tracesSampleRate or tracesSampler, so leave them unset to send errors only.
Sources
- Sentry docs: JavaScript SDK options (sampleRate, ignoreErrors, denyUrls, beforeSend, tracesSampleRate) (read 2026-11-13)
- Sentry docs: Spike Protection (read 2026-11-13)
Related
Sentry is a trademark of its owner; Bugsly is not affiliated with or endorsed by Sentry. “Sentry-compatible” only means Bugsly accepts events sent by Sentry's open SDKs.