Error tracking cost: when one noisy exception eats your whole quota

Error tracking has an unusual cost profile: it is cheap almost all the time and catastrophically expensive for a few hours at a time. The bill correlates with incidents rather than with traffic, which means the month you had a bad deploy is the month your observability spend spikes, right when nobody has attention to spare for cost.

How error platforms bill

The key phrase is "per event received". Platforms group similar errors into issues for your convenience, but grouping happens after ingestion and after billing. Ten thousand instances of the same null pointer exception show as one issue in the UI and ten thousand events on the invoice.

The incident math

Take a service handling 2,000 requests per second. A dependency starts failing and every request throws. With a client library capturing every exception, you emit 2,000 events per second, 7.2 million per hour. At $0.0005 per event that is $3,600 for one hour of a failing dependency.

Retry logic makes it worse. A three-attempt retry with exponential backoff triples the error count and extends it beyond the incident window. Background job frameworks that retry failed jobs indefinitely can emit errors long after the underlying issue resolved. A job queue with 50,000 stuck messages retrying every 30 seconds produces 100,000 errors per minute indefinitely, which nobody notices because it does not page.

The three controls

Client-side rate limiting is the most important and the least used. Every mature error SDK supports a cap on events per time window per process. Set it to something like 20 events per minute per process. During normal operation you never hit it; during an incident it caps your exposure at a few hundred dollars instead of a few thousand. The tenth thousand instance of an exception tells you nothing the tenth did not.

Fingerprint-based sampling is second. Compute a fingerprint from the exception type and stack trace, keep the first N occurrences at full fidelity, then sample subsequent occurrences at 0.1% while maintaining an accurate local count you attach as an attribute. You get the exact frequency and a handful of full examples, which is all anyone uses.

Server-side inbound filters are third and cover what the clients miss. Every platform supports dropping events matching patterns before they count against quota: browser extension errors, bot traffic, known third-party script failures, and errors from unsupported browser versions. On a consumer web application, browser noise routinely accounts for 30% to 60% of received events and essentially none of the actionable ones.

Session replay deserves its own policy

At $0.003 to $0.03 per replay, session replay is 10x to 60x the price of an error event and it is easy to enable broadly. Recording 100% of sessions on a site with 3 million monthly sessions at $0.01 each is $30,000 per month. Recording only sessions in which an error occurred, typically 1% to 3% of sessions, brings that to $300 to $900 while capturing the replays anyone actually watches. Set replay sampling to error-triggered by default and raise it deliberately for a specific investigation.

Reducing the error rate itself

The cheapest error event is the one not thrown. Expected conditions should not be exceptions: a 404 on a deleted resource, a validation failure on user input, a rate limit response from a third party. These frequently make up the majority of captured events and represent normal operation. Filter them by type in the client rather than sending them and grouping them away in the UI.

Also check what your framework captures by default. Many web frameworks report every 4xx response as an error, which means a crawler probing for admin paths generates thousands of billable events per day. Restrict default capture to 5xx and unhandled exceptions.

Budget alarms, not surprises

Because error cost spikes with incidents rather than accumulating steadily, a monthly budget alert fires too late. Set a rate-based alert: notify when error events exceed, say, 5x the 7-day trailing average for more than 10 minutes. That catches the runaway before it runs for three days, and it doubles as a useful reliability signal. Pair this with the broader observability cost controls, and price the supporting infrastructure from Terraform against the resource catalog so the whole telemetry estate carries a number.

FAQ

What to do next

Keep the whole telemetry estate priced. C3X reads your Terraform and prices observability infrastructure against a live catalog. Start with the quickstart.