Cloud Run pricing looks simple until someone asks a very normal question:
"How much is this service actually going to cost me each month?"
A lot of people jump straight to request count. In practice, that is often not the part that matters most. For many workloads, CPU time is the real cost driver.
The good news is that you do not need a perfect spreadsheet to get a useful estimate. If you know a few inputs, you can get close enough to make better decisions before you deploy.
The four numbers that matter
For a basic Cloud Run estimate, you mostly care about:
- monthly requests
- average request duration
- CPU allocated per instance
- memory allocated per instance
If you expect outbound traffic, add egress as well.
That is the core of it. Cloud Run pricing is granular, but it is not random.
The basic model
A simple estimate comes down to two usage calculations:
vCPU-seconds = monthly requests * (duration_ms / 1000) * vCPUs
GB-seconds = monthly requests * (duration_ms / 1000) * (memory_MB / 1024)
From there, Cloud Run adds request charges and networking egress.
The current calculator on CloudWebSchool uses these published pricing constants:
- CPU: $0.00002400 per vCPU-second
- Memory: $0.00000250 per GB-second
- Requests: $0.40 per million
- Egress: $0.12 per GB
It also applies the free tier if you want a more realistic estimate:
- 2,000,000 free requests per month
- 360,000 free vCPU-seconds per month
- 180,000 free GB-seconds per month
- 1 free GB of egress per month
One detail people miss: the free tier is per billing account per month, not per service.
A worked example
Let us use one of the calculator's example workloads:
- 10 million requests per month
- 200 ms average duration
- 1 vCPU
- 512 MB memory
- 5 GB egress
- free tier applied
That lands at roughly $45/month.
The breakdown is the useful part:
- CPU: $39.36
- Memory: $2.05
- Requests: $3.20
- Egress: $0.48
This tells you something important straight away: the bill is mostly CPU time, not request count.
If you cut average duration from 200 ms to 100 ms, the total cost drops sharply.
The calculator's scenario notes that halving duration roughly halves the bill.
That is the kind of optimisation insight you want before tweaking settings blindly.
What developers usually get wrong
1. Treating request count as the whole story
A service can handle a lot of requests and still stay cheap if each request is short and the free tier absorbs part of the traffic.
For example:
- 100,000 monthly requests
- 300 ms duration
- 256 MB memory
- 1 vCPU
This comes out at about $0/month, because it stays inside the free tier.
2. Ignoring infrastructure outside request handling
A simple Cloud Run estimate is useful, but it is not the whole bill if you also use:
- minimum instances
- always-allocated CPU
- Cloud SQL
- Secret Manager API calls
- load balancing
- VPC connectors
- Artifact Registry storage
That is why it is best to treat the estimate as a baseline, not a promise.
How to use this in practice
If you are sizing a new service, start with a rough model before touching production settings.
Ask yourself:
- How many requests do I expect each month?
- What is the average request duration?
- Do I really need this much CPU and memory?
- Is my service actually CPU-bound, or just slow?
That last question matters more than most people think.
If CPU time dominates your bill, then improving latency is not just a performance win.
It is also a cost optimisation.
If you want to test your own numbers, the Cloud Run Cost Calculator lets you plug in:
- request volume
- request duration
- CPU allocation
- memory allocation
- network egress
directly in the browser.
If you are tuning minimum instances, concurrency, or memory, the longer Cloud Run cost optimisation guide goes deeper into those trade-offs.
Conclusion
Cloud Run pricing becomes much easier to reason about once you stop guessing.
For many services, the biggest lever is not:
"How many requests do I have?"
but rather:
"How much CPU time does each request burn?"
Get that right and your estimates become much more reliable.
Try the calculator
If you want to run the numbers on your own workload, try the full Cloud Run Cost Calculator:
It is free, browser-based, and useful for quick planning before changing production settings.
Top comments (0)