A Slack-driven DNC compliance service — scrubbing across multiple dialer platforms on demand — came in at over $120 for the month on Google Cloud Run. For a tool handling 1-5 requests a day, a few seconds of real work each time, that number should raise a flag. Here’s what actually drives a bill like that, why it’s almost always a configuration problem rather than a workload problem — and what the alternative actually costs if the compliance layer isn’t there at all.
Where the Money Actually Goes
Broken down by service, the overwhelming majority of that bill — well over 80% — came from Cloud Run itself, not from Firestore, not from logging, not from Slack API calls. Cloud Run was the cost driver by a wide margin, and that’s true across every billing period I’ve looked at for a service shaped like this one.
That’s the tell. A DNC scrub job runs for a few seconds: receive the Slack command, fan out to each dialer platform’s API in parallel, log the result, return a confirmation. At real-world volume — 1 to 5 requests a day for a service like this, not dozens — the actual compute time involved is trivial. Google’s own Cloud Run pricing bills in 100-millisecond increments for the time a request is actively processing. At that granularity, real usage for this kind of service should cost cents, not tens of dollars.
The Complication: Cloud Run Has Two Different Billing Modes, and Only One of Them Is Cheap
Cloud Run can run two ways. With min-instances left at the default (0), the service scales to zero between requests — no container running, no cost, until a request comes in. That’s the cheap mode, and it’s the right mode for a service that fires a handful of times a day.
Set min-instances above zero — often done to avoid cold-start latency, so the first request of the day doesn’t wait a few extra seconds for a container to spin up — and Cloud Run keeps that container running continuously, billed by the hour, whether or not a request ever arrives. A container idling 24 hours a day for a service that’s doing maybe a minute of real work total across 1-5 requests is paying for roughly 1,440 minutes of standby to cover under sixty seconds of actual compute.
That ratio is the entire story behind a bill in the hundred-dollar range for a service this size. It’s very rarely the compliance logic itself, the Firestore reads, or the Slack integration driving the cost — those are all cheap at this volume, consistently, across every deployment I’ve diagnosed. It’s almost always an idle container burning hours it doesn’t need to.
Why this kind of waste survives unnoticed: a service handling 1-5 requests a day, running reliably for over a year without a missed removal, doesn’t attract scrutiny. It works. Nobody questions a line item that quietly does its job. That reliability is exactly what makes the billing mismatch easy to miss — a service that’s never failed is the last place anyone thinks to look for a 5-10x cost leak.
What Not Having This Actually Costs
The Cloud Run bill is the wrong number to fixate on. It’s the smallest number in this entire conversation. Here’s the number that actually matters: under the TCPA, statutory damages run $500 per negligent violation, up to $1,500 per violation if a court finds it willful or knowing — and that’s per call or text, not per campaign. No actual harm needs to be proven. Each mis-dialed number is its own exposure.
To make that concrete, here’s a deliberately conservative model — not a claimed industry statistic, just simple math anyone can check against their own numbers. Assume 150 dials per agent per day, 20 dialing days a month, and a stale-data or missed-scrub rate of just 0.1% — one bad number in a thousand, which is a conservative assumption, not a worst case:
Small operation (15 seats): ~45,000 dials/month → ~45 violations/month at that rate → $22,500/month exposure at the standard rate, up to $67,500/month if willful.
Medium operation (40 seats): ~120,000 dials/month → ~120 violations/month → $60,000/month standard, up to $180,000/month willful.
Large operation (100+ seats): ~300,000 dials/month → ~300 violations/month → $150,000/month standard, up to $450,000/month willful.
Put the two numbers next to each other: even the worst-case, badly-configured version of this tool — the $120/month one — costs less than a single violation at the small end of that table. A whole year of running it inefficiently costs less than one bad afternoon of unscrubbed dials at any of these scales. The Cloud Run bill was never the risk. It’s the insurance premium, and it’s cheap insurance even when it’s paying for a mistake in how it’s deployed.
What a Correctly-Configured Version Should Cost
To be direct about what’s confirmed and what isn’t: the cost pattern above is real, drawn from actual hands-on diagnosis of a service shaped exactly like this. A specific target number for what it should cost after fixing the configuration isn’t something to state as fact without actually making the change and measuring the result on a given deployment — and this post isn’t going to hand you a precise number that hasn’t been verified for your setup.
What can be said with real confidence: at request volumes this low — 1-5 a day is typical for a single-purpose compliance tool like this — a properly scale-to-zero Cloud Run service billed per 100ms of actual processing time should land in the low tens of dollars a month, not over a hundred. The gap between “should” and “does” is almost entirely the min-instances setting — checking it is a five-minute diagnostic, not a rebuild.
Frequently Asked Questions
Does scaling to zero bring back cold-start delays?
Yes — the first request after idle time waits for a new container to spin up, typically a few seconds. For a Slack-triggered compliance tool where a manager submits a request and waits for confirmation, a few seconds of occasional added latency is a reasonable trade against paying for 24/7 standby the tool doesn’t need.
Is this specific to DNC compliance tools, or a general Cloud Run problem?
General — any low-frequency, on-demand service (compliance scrubs, scheduled reports, Slack-triggered automations) is exposed to this same trap. DNC compliance tooling is a common example because the request pattern — infrequent, bursty, tolerant of a few seconds’ latency — is exactly the shape scale-to-zero billing is built for.
How do I check what my own service is actually configured for?
The Cloud Run service’s configuration page shows the minimum instance count directly. If it’s set above zero, that’s the first thing worth changing before looking anywhere else in the stack.
Is the 0.1% violation rate realistic?
It’s a conservative planning assumption, not a measured industry average — actual rates depend heavily on list hygiene, how often numbers are re-scrubbed, and how aggressively a list is worked. The point of the model isn’t the exact rate; it’s that even a very low rate produces exposure that dwarfs the cost of the tooling meant to prevent it.
If You’d Rather Have This Audited
I build and run this kind of compliance automation for contact centers, and I check the deployment cost the same way I check the compliance logic — for real, not assumed. If you want your own DNC tooling built correctly from the start, or an existing setup checked for exactly this kind of silent cost leak: rfditservices.com/intake.html
The first conversation is free.
Leave a Reply