Serverless cost spikes: check your error rate before you check your bill

A recent beta run against a mid-market healthcare SaaS company's Datadog org flagged two serverless product families forecasted to jump hard this month: serverless_apps projected up 41.7% (from $51.84 completed last month to roughly $73.44 this month) and serverless_apps_apm projected up 25.0% ($72.00 to roughly $90.00). The month before, the account's total spend had risen a modest 3.6%. Two families suddenly accelerating past that baseline, in the same month, is the kind of thing worth looking at before it becomes next month's invoice — not after.

The instinct when a serverless line item jumps is to assume traffic grew. It's a reasonable first guess, and sometimes it's the right one. But there's a second, easy-to-miss cause that produces the exact same symptom on the cost dashboard while looking completely different in your actual application logs: errors.

Why a bug can cost as much as real traffic growth

Serverless platforms bill per invocation, and most of them retry failed invocations automatically. AWS Lambda retries asynchronous invocations on error by default; Cloud Run and Cloud Functions have their own managed-retry behavior for failed requests under certain configurations. Each retry is a new invocation from the platform's perspective — and a new invocation is a billed invocation, identical on the cost side to a legitimate one. That means a code change that starts throwing errors on some fraction of requests doesn't just produce failed responses; it can quietly multiply your invocation volume, because every failure spawns one or more follow-up attempts. The cost dashboard shows a jump. The traffic graph, if you're only looking at request count from your load balancer or API gateway rather than invocation count at the function layer, might show nothing unusual at all.

This is exactly the pattern the report flagged for both serverless families here, with the same instruction attached to each: investigate, don't sign a contract yet.

Product family	Forecasted change	Cost impact this month	Metrics to audit
serverless_apps	+41.7%	$21.60	aws.lambda.invocations, aws.lambda.errors
serverless_apps_apm	+25.0%	$18.00	aws.lambda.invocations, aws.lambda.errors

The actual check: two curves, side by side

The concrete thing to do costs nothing and takes a few minutes: pull aws.lambda.invocations and aws.lambda.errors (or the equivalent request-count and error-count metrics if you're on Cloud Run or Cloud Functions) for the same window as the cost jump, and look at whether the error curve moved in step with the invocation curve. If error count climbed right as invocation count — and therefore cost — climbed, that's the signal: something in your deploys or config around the same window started failing, and the retries are the bulk of the new spend. If errors stayed flat while invocations climbed on their own, that's a genuine traffic story instead, and the conversation shifts to whether that growth is expected and sustained.

Either way, cross-reference against your own deploy history for the same window — a config change, a dependency bump, a new downstream integration starting to time out are all common triggers. This is the same "check what changed on the exact date" logic behind day-by-day usage analysis generally; we cover that mechanism in full in our post on why the day-by-day shape matters more than the monthly total — worth reading if you want the deeper version of "don't trust the aggregate number alone."

Be honest about what this is: a hypothesis, not a diagnosis

The report doesn't claim to know that errors caused this spike — it can't, from usage-cost data alone. What it can do is notice that a serverless family that's normally flat-ish just accelerated hard, and hand you the specific metrics most likely to explain why. Whether the error curve actually matches is something a person has to open the dashboard and look at. That's a deliberate design choice: a tool that guessed "it's probably a bug" and moved on would be worse than one that says "check these two metrics, here's exactly why."

Why the sequencing matters

Both findings here carry the same explicit note: "what you give up: nothing — this is an investigation, not a commitment." That's worth sitting with. Investigating an error-driven spike costs you the few minutes it takes to pull two metrics. Committing to a 12-month contract rate based on a spike that turns out to be a retry storm from a bug that gets fixed next sprint costs you a year of an inflated baseline. The report's own guidance is blunt about the order of operations: look at the error rate this week; only revisit the contract question once you know whether this month's number is real, sustained usage or a temporary artifact of something broken.