Deploying an application to Google Cloud Run is relatively straightforward. You can package your application in a container, deploy it, and let Cloud Run handle infrastructure scaling.
The cost side requires more planning.
Cloud Run can automatically create additional instances when application traffic increases. This is useful for applications with unpredictable workloads, but it also means that resource consumption can grow when traffic spikes or an application behaves unexpectedly.
A sudden increase in requests, an inefficient background process, or an automated traffic source can increase your cloud bill. Even applications with low normal traffic can experience unexpected costs if they are not configured carefully.
Cloud Run provides several controls that help teams manage resource consumption, including maximum instance limits, concurrency settings, CPU and memory allocation, request timeouts, and billing alerts.
However, these controls serve different purposes. A maximum instance setting can restrict application scaling, but it does not establish a fixed monthly spending cap.
In this article, we will examine how Cloud Run billing works, how to configure resource limits, how to create budget alerts, and how to prepare an application for production without allowing unexpected traffic to create unnecessary cloud costs.
Understanding How Cloud Run Costs Are Generated
Cloud Run is a managed platform for running containerized applications.
You deploy a container image, configure its resources, and Cloud Run manages the underlying infrastructure.
Depending on the billing configuration, charges can be associated with:
- CPU allocation and usage.
- Memory allocation and usage.
- Number of requests.
- Minimum instances kept available.
- Network data transfer.
- Other Google Cloud services used by the application.
For example, a Cloud Run application might connect to Cloud SQL, store files in Cloud Storage, or publish messages through Pub/Sub. These services can generate additional costs outside the Cloud Run service itself.
This distinction is important when estimating the total application cost.
Request-Based Billing
With request-based billing, Cloud Run generally charges for allocated CPU and memory while instances are processing requests, along with request charges.
This model can work well for applications with intermittent traffic because instances can scale down when there is no work to process.
Instance-Based Billing
With instance-based billing, CPU and memory are billed for the lifetime of the instance, including periods when it is not actively processing requests.
This can be useful for workloads that need background processing or CPU availability outside request handling, but it requires careful resource planning.
The billing model should match the application's execution pattern.
| Area |
Request-based billing |
Instance-based billing |
| CPU allocation |
Primarily during request processing |
Throughout the instance lifecycle |
| Memory allocation |
Based on request-processing allocation |
Throughout the instance lifecycle |
| Background processing |
Has restrictions depending on CPU allocation |
Better suited to continuous background work |
| Idle instance cost |
Depends on minimum instances and configuration |
Can continue while instances remain active |
| Typical use case |
Request-driven APIs and web applications |
Background workers and continuously active workloads |
Check the current Cloud Run pricing and billing configuration before estimating costs. Pricing can vary by region and configuration.
Why Cloud Run Can Become Expensive
Automatic scaling is useful, but it does not automatically protect an application from every source of unexpected consumption.
Consider an application that normally receives 100 requests per minute.
One day, an automated client starts sending thousands of requests per minute. Cloud Run may create additional instances to handle the incoming workload, subject to the configured scaling limits.
If the application has no maximum instance limit, resource consumption can increase significantly.
Other situations can also affect costs.
Unexpected Traffic Spikes
A marketing campaign, public API exposure, or automated traffic can increase request volume.
Even legitimate traffic can exceed the capacity assumptions used during deployment.
Incorrect Autoscaling Configuration
A service configured with a high maximum instance count may create more instances than the application actually needs.
This is particularly important when each instance consumes substantial memory or CPU resources.
Inefficient Application Code
An application that performs unnecessary database queries, repeatedly processes the same data, or waits on external services can consume more resources than expected.
Scaling may hide these performance problems temporarily, but it can increase infrastructure costs.
Background Processing
Background tasks that run continuously can keep instances active.
If the workload does not require continuous execution, consider whether a scheduled job or event-driven architecture would be more appropriate.
Minimum Instances
Configuring minimum instances can reduce cold starts and improve response times.
However, keeping instances available can increase costs even when request volume is low.
The performance benefit should be compared with the additional cost.
Configuring Maximum Instances to Control Scaling
One of the most useful controls for managing Cloud Run resource consumption is the maximum instance setting.
It limits the number of instances that a service or revision can create.
Suppose an application normally handles its workload with two instances.
You might configure a maximum of five instances to allow some growth while preventing unlimited scaling.
Configure Maximum Instances Using the Google Cloud Console
- Open the Google Cloud Console.
- Navigate to Cloud Run.
- Select the service you want to configure.
- Open the service configuration or edit deployment settings.
- Locate the scaling configuration.
- Set the maximum number of instances.
- Review the configuration and deploy the new revision.
The exact console layout may change, but the scaling configuration is available through the Cloud Run service settings.
Configure Maximum Instances Using the Google Cloud CLI
You can also configure the maximum number of instances during deployment.
For example:
gcloud run deploy payment-api \
--image=us-central1-docker.pkg.dev/my-project/apps/payment-api \
--region=us-central1 \
--max=5
This example deploys a Cloud Run service with a maximum of five instances.
Replace the service name, image, project, and region with your actual configuration.
You can also update an existing service:
gcloud run services update payment-api \
--region=us-central1 \
--max=5
The maximum instance setting limits scaling, but it does not guarantee that every incoming request will be processed successfully.
If traffic exceeds the capacity of the available instances, requests may experience increased latency, queuing, or failures.
Choose the limit based on expected traffic and application performance.
Understanding Maximum Instances at Service and Revision Levels
Cloud Run supports scaling controls at different levels.
A service can have multiple revisions during deployments. Traffic may be distributed across these revisions.
When configuring scaling, understand whether the limit applies at the service level or to an individual revision.
For example, consider a service with two revisions:
- Revision A receives 70% of traffic.
- Revision B receives 30% of traffic.
If each revision is configured with its own maximum instance count, the total number of instances across the service may be higher than expected.
For this reason, review revision-level and service-level scaling settings when using gradual rollouts or traffic splitting.
Do not assume that a limit configured for one revision automatically represents the total resource limit for the entire application.
Configure CPU and Memory Limits
Maximum instances control how many containers can run. CPU and memory settings control the resources available to each instance.
Both settings affect application performance and cost.
Consider an application configured with:
- Maximum instances: 5.
- CPU: 2 vCPUs per instance.
- Memory: 2 GiB per instance.
Its configured maximum capacity would be:
| Resource |
Per instance |
Maximum instances |
Configured total |
| CPU |
2 vCPUs |
5 |
10 vCPUs |
| Memory |
2 GiB |
5 |
10 GiB |
This is a capacity illustration, not a monthly cost estimate.
The actual bill depends on the billing model, instance activity, region, and other configuration details.
Configure CPU and Memory During Deployment
Use the following command:
gcloud run deploy payment-api \
--image=us-central1-docker.pkg.dev/my-project/apps/payment-api \
--region=us-central1 \
--cpu=1 \
--memory=512Mi \
--max=5
This configuration provides one vCPU and 512 MiB of memory per instance, with a maximum of five instances.
Start with realistic resource requirements and monitor the application under representative load.
Do not assign large CPU and memory limits simply because they are available.
What Happens When Memory Is Insufficient?
If an application exceeds its allocated memory, the container can be terminated.
This may result in failed requests or instance restarts.
Common causes include:
- Loading large files entirely into memory.
- Keeping too many objects in memory.
- Processing large batches without limits.
- Memory leaks.
- Creating excessive concurrent tasks.
Use Cloud Monitoring to examine memory utilization before increasing the allocation.
Configure Concurrency to Improve Resource Utilization
Concurrency controls how many requests a Cloud Run instance can process simultaneously.
For example, a service configured with a concurrency value of 80 can process up to 80 concurrent requests per instance, subject to the application's actual capabilities and other platform limits.
Higher concurrency can improve resource utilization for applications that handle simultaneous requests efficiently.
However, it is not always the right choice.
An application that uses substantial memory per request may run out of memory when too many requests execute simultaneously.
Similarly, an application that uses a shared resource without proper synchronization may experience performance problems at higher concurrency.
Configure Concurrency
gcloud run services update payment-api \
--region=us-central1 \
--concurrency=40
This example configures the service to process up to 40 concurrent requests per instance.
Choose a value through load testing rather than relying on a generic default.
For a lightweight API that performs mostly asynchronous network operations, a higher concurrency setting may be suitable.
For CPU-intensive workloads, a lower value may provide more predictable performance.
Set Request Timeouts
Long-running requests can consume resources for longer than expected.
Cloud Run allows you to configure a request timeout, which determines how long the platform waits for a request to complete before returning a timeout error.
For example:
gcloud run services update payment-api \
--region=us-central1 \
--timeout=60s
This sets the request timeout to 60 seconds.
Choose the timeout based on the operation being performed.
A simple authentication endpoint should not normally need the same timeout as a report-generation endpoint.
If an operation takes several minutes, consider moving it to an asynchronous processing workflow instead of keeping an HTTP request open.
A timeout does not necessarily stop every downstream operation immediately. Your application should also implement cancellation, connection timeouts, and appropriate cleanup.
Configure Google Cloud Budget Alerts
Maximum instances and resource settings control application capacity. Budget alerts help teams monitor spending across Google Cloud projects.
A budget alert can notify administrators when spending reaches configured thresholds.
For example, you might create a monthly budget of ₹10,000 and configure notifications at:
- 50% of the budget.
- 80% of the budget.
- 100% of the budget.
These percentages are examples. Choose thresholds based on your application's expected spending and response time.
Create a Budget in Google Cloud
- Open the Google Cloud Console.
- Navigate to Billing.
- Select the billing account associated with your project.
- Open Budgets and alerts.
- Create a new budget.
- Select the projects or services to include.
- Enter the budget amount.
- Configure alert thresholds.
- Select the notification recipients.
- Save the budget.
You can create a project-specific budget to monitor the application independently from other workloads.
For better visibility, consider creating separate budgets for development, testing, and production environments.
Important: Budget Alerts Are Not Spending Caps
This is one of the most important distinctions in Google Cloud cost management.
A budget alert does not automatically stop your Cloud Run service when spending reaches the configured amount.
It is a notification mechanism.
If a project reaches its budget threshold, resources can continue running and generating charges.
For automated cost control, you need an additional mechanism that responds to billing information or resource usage. Such automation should be designed carefully because billing data can be delayed, and shutting down a service based only on a budget notification can interrupt legitimate traffic.
Estimate Cloud Run Costs Before Deployment
Before making an application public, estimate its expected resource consumption.
Start with a few measurable assumptions:
- Expected requests per month.
- Average request duration.
- CPU allocation.
- Memory allocation.
- Expected number of instances.
- Minimum instance configuration.
- Billing model.
- Network and dependent service usage.
For example, suppose an API has the following expected workload:
| Configuration |
Planned value |
| Monthly requests |
500,000 |
| CPU per instance |
1 vCPU |
| Memory per instance |
512 MiB |
| Maximum instances |
5 |
| Minimum instances |
0 |
| Request timeout |
60 seconds |
| Maximum concurrency |
40 |
These values provide a starting point for capacity planning.
They do not produce an exact bill by themselves. Actual cost depends on the time resources are allocated, the selected billing model, regional pricing, and additional services.
Use the Google Cloud pricing calculator and billing reports to estimate and validate the expected expenditure.
Monitor Cloud Run Usage After Deployment
Cost management should continue after the application goes live.
Cloud Monitoring provides metrics that help teams understand how the service behaves under real traffic.
Monitor the following areas:
| Metric or area |
What to investigate |
| Request count |
Sudden increases in incoming traffic |
| Request latency |
Slow operations and inefficient code |
| Instance count |
Unexpected scaling activity |
| CPU utilization |
CPU-intensive operations |
| Memory utilization |
Memory leaks and oversized workloads |
| Request errors |
Failed requests and capacity problems |
| Container startup time |
Slow initialization and dependency loading |
Create alerts for unusual traffic increases, high resource utilization, and elevated error rates.
Cloud Billing reports can help identify which services and projects contribute most to spending.
For more detailed cost analysis, use billing exports to BigQuery and examine resource usage over time.
Best Practices for Keeping Cloud Run Costs Under Control
Start With Conservative Resource Settings
Do not allocate maximum CPU and memory during the initial deployment without measuring application requirements.
Start with a reasonable configuration and increase resources when monitoring and load testing demonstrate a need.
Set Maximum Instance Limits
Choose a maximum instance count based on the expected workload and the application's downstream capacity.
For example, if your database can handle only a limited number of connections, allowing Cloud Run to create too many instances may overload the database.
Test Concurrency Under Load
Use load testing to determine how many simultaneous requests an instance can handle without unacceptable latency or memory consumption.
Configure Minimum Instances Only When Necessary
Minimum instances can improve startup latency, but they may increase costs.
Use them when the application's latency requirements justify the additional resource allocation.
Protect Public Endpoints
If an endpoint is intended only for internal applications, configure authentication and appropriate access controls.
For public endpoints, use rate limiting, API gateways, or other protective controls where appropriate.
Authentication does not replace cost controls, but it can reduce unauthorized access to sensitive operations.
Review Dependent Service Limits
Cloud Run may scale successfully while a connected database or external API becomes overloaded.
Set appropriate connection pool limits, request timeouts, and retry policies.
Review Costs Regularly
Check billing reports and usage metrics regularly, especially after deployments, traffic changes, or configuration updates.
Do not wait until the end of the month to investigate an unexpected increase.
Common Mistakes When Configuring Cloud Run Spending Controls
| Mistake |
Potential impact |
Better approach |
| Treating budget alerts as hard limits |
Spending can continue after an alert |
Add a separate response mechanism if needed |
| Leaving maximum instances unrestricted |
Unexpected scaling can increase resource usage |
Configure appropriate scaling limits |
| Setting CPU and memory too high |
Unnecessary resource allocation |
Measure actual application requirements |
| Setting concurrency too high |
Memory pressure and slower requests |
Test under realistic traffic |
| Keeping too many minimum instances |
Higher idle resource costs |
Configure minimum instances only when justified |
| Ignoring database connection limits |
Database overload during scaling |
Control connection pools and instance counts |
| Ignoring network costs |
Total bill exceeds Cloud Run estimate |
Include dependent services and data transfer |
| Deploying without load testing |
Production capacity is uncertain |
Test expected and peak workloads |
Advantages and Disadvantages of Cloud Run Cost Controls
Advantages
- Maximum instance settings help restrict application scaling.
- CPU and memory limits make resource allocation more predictable.
- Concurrency settings help control workload distribution.
- Request timeouts prevent requests from running indefinitely.
- Budget alerts improve spending visibility.
- Cloud Monitoring helps identify unusual resource consumption.
- The configuration can be managed through the console, CLI, and deployment automation.
Disadvantages
- Maximum instance limits can reduce availability during traffic spikes.
- Budget alerts do not automatically stop spending.
- Restrictive CPU and memory settings can cause application failures.
- Incorrect concurrency settings can reduce performance.
- Minimum instances can increase costs.
- Cost estimation requires considering other Google Cloud services, not just Cloud Run.
Summary
Cloud Run makes it easier to deploy containerized applications without managing servers, but automatic scaling should be configured with cost and capacity limits in mind.
Before launching an application, configure maximum instances, CPU, memory, concurrency, and request timeouts based on realistic workload expectations.
Create Google Cloud budget alerts to monitor spending, but remember that alerts are not hard spending caps. Use Cloud Monitoring and billing reports to understand actual resource consumption after deployment.
A practical cost management strategy combines resource limits, application-level optimization, access controls, monitoring, and regular billing reviews.
The goal is not to prevent an application from scaling. It is to ensure that scaling happens within a capacity and cost range that your application, database, and business can support.
Join the conversation! Your thoughts help the community grow.