# Minimum instances and startup CPU boost: what a cold start costs, and what it costs to skip it

> Startup CPU boost makes every start faster for a fraction of a cent; a minimum instance skips the wait for about $8 to $10 a month. How each works, how to measure first, the costs and the traps.

Published 2026-10-12 · Updated 2026-10-13 · [By Exodus team](https://exodus.elim.io/about) · Performance, Pricing
<https://exodus.elim.io/blog/min-instances-and-startup-cpu-boost>

A cold start on Cloud Run is the wait for a new instance when none is running; for a small app it is usually under a second, 0.57 s at the median for our eight services. Startup CPU boost shortens every start for a fraction of a cent and is on by default for new services. One minimum instance removes the wait for about $8 to $10 a month.

## In short

- Our eight services started an instance in 0.57 s at the median and 2.25 s at worst; a first request on a new instance took 0.43 s, later ones 0.002 s.
- Startup CPU boost raises a 1 vCPU instance to 2 during startup and for 10 seconds after, at most $0.000252 for a half-second start.
- One idle minimum instance of 1 vCPU and 512 MiB costs $9.86 a month on request-based billing in europe-west1, $49.93 on instance-based.
- Set it at the service level with `--min 1`; it is a best-effort target, and Google suggests 3 for a service that must stay up.

Prices are list prices of October 12, 2026.

## What a cold start is and when it happens

An **instance** is one running copy of your container. Cloud Run adds instances when traffic grows and removes them when it falls; Google calls this autoscaling. When a revision gets no traffic, it scales to zero by default. From zero, the only thing that starts an instance is a request that finds none: Google's autoscaling page calls this on-demand scaling and says it is "the only driver for scaling from zero".

The start itself has three parts, in Google's words: downloading the container image, running the entrypoint command, and waiting for the container to listen on its port. Requests go to the container as soon as it listens. While it starts, the request waits in a queue, for up to 3.5 times the service's average startup time or 10 seconds, whichever is longer.

An idle instance does not vanish at once: Cloud Run may keep it for up to 15 minutes after its last request, and stops the least busy ones sooner. So a service with a request every few minutes usually finds an instance up, and one with a request an hour starts cold almost every time.

Cold starts also happen when traffic grows and when a new revision is deployed. Minimum instances help only from zero to one; Google's announcement of startup CPU boost says they "aren't a solution for all cold-starts as traffic scales out". Boost speeds up every start.

![Two lanes. With minimum instances 0, a request finds no instance, Cloud Run starts one (image, entrypoint, listen on PORT, with startup CPU boost raising 1 vCPU to 2 during the start and for 10 seconds after), then the request is answered; the request waits 0.43 s at the median in our project and 40 s for an old Java app on 1 CPU in our test. With minimum instances 1, a request after a quiet hour reaches a warm instance billed at the idle rate and is answered at once, for $9.86 a month at 1 vCPU and 512 MiB in europe-west1](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-93d82cbbbecdd6fb9a7750ab794c7f7eb8478408602e3cc70ab4428734b53a16-680x380-svg/bytes "What the first request after a quiet spell meets, with and without a minimum instance")

## Measure your own cold starts first

Cloud Run writes a line to its system log every time it starts an instance, with the reason. This command lists the last week of starts for one service:

```shell
gcloud logging read 'resource.type="cloud_run_revision"
  AND resource.labels.service_name="SERVICE"
  AND logName:"varlog%2Fsystem"
  AND textPayload:"Starting new instance"' \
  --freshness=7d \
  --format='value(timestamp,textPayload)'
```

Each line ends in a reason. `AUTOSCALING` means traffic needed an instance, which includes every start from zero; `DEPLOYMENT_ROLLOUT` means a new revision. If the list is short, you have few cold starts. If it shows a start every few minutes all day, you have many, and the next question is how long each one takes.

For that, Cloud Monitoring has the Cloud Run metric `container/startup_latencies`, with no setup. The logs give it too: the time from "Starting new instance" to the line that says the startup probe succeeded, as in our [health checks guide](https://exodus.elim.io/blog/health-checks-and-startup-probes). Our [logs and alerts guide](https://exodus.elim.io/blog/logs-metrics-and-alerts-for-a-cloud-run-app) explains how to read the system log, and [cold starts, measured](https://exodus.elim.io/blog/cloud-run-cold-start-measured) compares start times across platforms.

What a user feels is the latency of the request that waited. Cloud Run's request log carries the instance's id on every entry, so you can compare the first request each instance served against all later ones.

## What we found in our own project

We read 30 days of logs from our own Google Cloud project, eight small services, all read-only. Every one runs with 1 vCPU, 128 to 512 MiB of memory, minimum instances 0 and startup CPU boost on. Cloud Run started 671 instances in those 30 days: 623 for autoscaling and 48 for deploys.

![Terminal output with service names masked. A gcloud run services list command formatted as a table shows eight services, service-a to service-h, each with MIN 0, MAX 1 or 3, BOOST true, CPU 1 and MEMORY 128Mi to 512Mi. A second command counts 30 days of instance starts by reason: 623 AUTOSCALING and 48 DEPLOYMENT_ROLLOUT](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-21684376775419878717ad13736a7fe14218c4d495f6a483059cdd257aadd3c9-680x334-svg/bytes "Our eight services: none keeps a warm instance, all have boost on, and they started 671 instances in a month")

From "Starting new instance" to the probe's success took 0.57 s at the median, 0.84 s at the 90th percentile, 1.49 s at the 99th, and 2.25 s at worst. These are small apps; the old Java sample in our test below took 40 s at 1 CPU.

Of 18,602 requests, 636 were the first on a new instance, 3.4%. Their median latency was 0.43 s; the median of every later request was 0.002 s. For one request in thirty the app was about two hundred times slower, and the difference was the start.

![A bar chart of median request latency over 30 days. Service A: first request on a new instance 0.42 s, every later request 0.002 s, 238 of 6,772 requests were first. Service B: 0.62 s against 0.001 s, 153 of 1,677. All eight services: 0.43 s against 0.002 s, 636 of 18,602](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-040211435041b770168cbe8422846d4ccdf2844e7476553297babc337bcbf213-680x340-svg/bytes "The first request on a new instance against every later one, in our request log")

Is half a second worth $9.86 a month? For service A, one minimum instance would remove most of 238 waits of about 0.42 s, some 100 seconds of waiting in a month, on an internal tool. For a public page whose first morning visitor is a customer, the answer can differ. One minimum instance on each of our eight services would cost $68.16 a month at their sizes. We keep them at zero.

## Startup CPU boost

Startup CPU boost gives an instance more CPU while it starts and for 10 seconds after. The amount depends on the CPU limit, from Google's CPU page:

- a limit up to 1 vCPU is boosted to 2;
- 2 vCPU to 4;
- 4, 6 or 8 vCPU to 8.

Sidecar containers are boosted too. Much of a start is CPU work: loading code, compiling it just in time, reading configuration. An app that can use two threads at once gains the most; Google's announcement explains Node.js's smaller gain by its single thread.

`gcloud` turns boost on for new services when you do not say otherwise ("Enabled by default when unspecified on new services", in the help of `gcloud run deploy`). Services made other ways may have it off. To check one service and to turn boost on or off:

```shell
gcloud run services describe SERVICE --region REGION \
  --format='value(spec.template.metadata.annotations."run.googleapis.com/startup-cpu-boost")'

gcloud run services update SERVICE --region REGION --cpu-boost
gcloud run services update SERVICE --region REGION --no-cpu-boost
```

The first prints `true` when boost is on. The setting is an annotation on the revision, so a change deploys a new revision.

### How much it helps

Google's 2022 announcement reported startup up to 50% faster for the Spring PetClinic sample, 47% for a native Spring service built with GraalVM, 23% for a plain Java function, and up to 30% for Node.js. Its Java tips page repeats "up to 50%".

We could not switch boost off in our project to test it without a production change, so we measured the same effect on our build machine, with Docker limiting the container to 1 CPU and then 2, five starts each, timing from `docker run` to the first answer on the port. This is not Cloud Run; it shows what one extra CPU does to a start.

![Two bar charts of median startup time over 5 starts. Spring PetClinic on Java: 40.62 s at 1 CPU, 20.43 s at 2 CPUs. A Node.js Express sample: 0.70 s at 1 CPU, 0.56 s at 2 CPUs. Docker alone takes 0.27 s. Measured on our build machine with Docker's CPU limit on Oct 12, 2026, not on Cloud Run](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-55e4a0646dbb6eb54dfea6d716d847f1824e81bd7b50f553e811705acc605839-680x330-svg/bytes "One extra CPU at startup: half the time for a Java app, a third less for a small Node.js app once Docker's own 0.27 s is taken out")

The Java app was the public Spring PetClinic image, an old build on Java 8 and Spring Boot 2.4.5: 40.6 s at 1 CPU, 20.4 s at 2. The Node.js app was a small Express sample: 0.70 s and 0.56 s, of which Docker itself took 0.27 s, so the app's own start fell by about a third. These match Google's numbers closely.

### What boost costs

You pay for the boosted CPU during startup and for the 10 seconds after. For a 1 vCPU service that starts in half a second, the extra is at most 10.5 vCPU-seconds, $0.000252 at the active rate of $0.000024 per vCPU-second. Our 671 starts a month would add at most $0.17.

For a slow start the arithmetic can come out even. The PetClinic start at 1 CPU bills 40.6 vCPU-seconds. With boost it is 20.4 seconds at 2 vCPU plus 10 seconds at 2 vCPU, at most 60.9 vCPU-seconds: about $0.0005 more per start, and memory is billed for 20 fewer seconds. For almost every service, boost is worth leaving on.

## Minimum instances

A minimum instance is an instance Cloud Run keeps running even when it serves nothing. With a minimum of 1, the first request after a quiet night reaches a warm instance and is answered without a start; that one instance can take as many requests at once as the service's concurrency allows, 80 by default. Above the minimum, Cloud Run scales as usual.

There are two places to set it, and Google recommends one of them.

- **Service level.** The flag `--min`. Set on the service, takes effect without deploying a new revision, and is divided among the revisions that receive traffic. This is the one Google recommends.
- **Revision level.** The flag `--min-instances`. Set on each new revision, so changing it deploys one. Google recommends not combining it with the service-level setting.

```shell
# keep one instance warm; takes effect without a new revision
gcloud run services update SERVICE --region REGION --min 1

# back to zero
gcloud run services update SERVICE --region REGION --min default

# see it: the "Scaling: Auto (Min: 1, Max: ...)" line
gcloud run services describe SERVICE --region REGION
```

`gcloud run deploy` takes the same `--min` flag. In a service YAML file the service-level setting is the annotation `run.googleapis.com/minScale` in the service's own metadata. Google's Terraform example sets `min_instance_count` in the `scaling` block of the revision `template`, which is the revision-level setting.

### How it behaves

A few rules from Google's page decide what you get for your money.

- **It is a target, not a promise.** Google calls it "a best-effort target". Minimum instances can be restarted at any time, and the count can drop for a while when a zone runs out of capacity, when Google rebalances machines, when your container crashes on start, or when a quota or disabled billing stops the project. For a service that must stay up, Google suggests at least 3.
- **Requests are spread across all minimum instances.** Set 10 and need 2, and all 10 do a little work. Set the minimum to what normal traffic needs.
- **A traffic split divides it.** A service minimum of 10 with a 50/50 split gives each revision 5.
- **Tags keep revisions warm.** With a revision-level minimum, every revision that has a traffic tag starts its minimum instances and keeps them, even with no traffic. Our [revisions and rollbacks guide](https://exodus.elim.io/blog/revisions-traffic-splitting-and-rollbacks) uses tags for previews; remove them when you are done, or use the service-level setting.
- **Maximum wins.** When minimums and maximums at the two levels disagree, the largest minimum wins, and any maximum caps it.

### A warm instance is not a background worker

On request-based billing, the default, an idle instance keeps its memory but gets almost no CPU. A minimum instance on request-based billing is warm, not working: a timer or a queue consumer inside it will not run between requests. Google's advice for work outside requests is instance-based billing together with at least one minimum instance. Our [billing guide](https://exodus.elim.io/blog/request-based-or-instance-based-billing) compares the two, and our guides on [Cloud Scheduler](https://exodus.elim.io/blog/cron-and-timers-with-cloud-scheduler) and [work after the response](https://exodus.elim.io/blog/work-after-the-response) show how to move timers and background jobs out of the instance, which is usually cheaper.

## What it costs

On request-based billing, an idle minimum instance has its own rate: in europe-west1 and the other Tier 1 regions (the lower-priced group in Google's pricing table), at list prices of October 12, 2026, $0.0000025 per vCPU-second and $0.0000025 per GiB-second. CPU is a tenth of the active rate of $0.000024; memory costs the same. Time spent serving requests is billed at the active rate as usual, the rates the [Cloud Run costs guide](https://exodus.elim.io/blog/what-cloud-run-costs) works through.

A month is 730 hours, 2,628,000 seconds. Per instance kept idle all month:

- 1 vCPU and 256 MiB: **$8.21**
- 1 vCPU and 512 MiB: **$9.86**, or $0.32 a day
- 2 vCPU and 1 GiB: **$19.71**
- three instances of 1 vCPU and 512 MiB, Google's suggestion for high availability: **$29.57**
- the same single instance on instance-based billing, where idle time is billed at the full rate of $0.000018 per vCPU-second and $0.000002 per GiB-second: **$49.93**

![A horizontal bar chart of what one month of minimum instances costs in europe-west1 at list prices of Oct 12, 2026: 1 vCPU and 256 MiB idle $8.21; 1 vCPU and 512 MiB idle $9.86; 2 vCPU and 1 GiB idle $19.71; three instances of 1 vCPU and 512 MiB idle $29.57; one instance of 1 vCPU and 512 MiB on instance-based billing $49.93](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-394edb0668008c76469cced936e37a55931f914c96c6b00ace9dd517646d043b-680x330-svg/bytes "A warm instance a month: a few dollars on request-based billing, five times more on instance-based")

Two more facts change these numbers a little.

- **The free tier.** Cloud Run's monthly free tier, 180,000 vCPU-seconds and 360,000 GiB-seconds on request-based billing, is described as "based on us-central1 active pricing" and applied as a discount on spend. The pricing page does not say whether it covers idle minimum time. Our [free tier guide](https://exodus.elim.io/blog/the-cloud-run-free-tier-explained) works the example both ways; either way, a minimum instance takes a service out of the free range.
- **Committed use discounts.** If you commit to an hourly spend for one or three years, request-based Cloud Run gets 17% off, which brings the 1 vCPU, 512 MiB instance to about $8.18. A commitment is worth it only for spend you are sure of for a year.

Cloud Run's Recommender does not suggest minimum instances or boost; its one cost recommendation is a switch to instance-based billing.

## Choosing

1. **Read the start log and the startup metric for a week.** If starts are rare or short, stop here.
1. **Check that boost is on.** It is the cheapest fix.
1. **Make the start shorter** (next section).
1. **If the first request must be fast** (a login page that must answer at 3 a.m., a webhook sender with a short timeout), set `--min 1` at the service level.
1. **If one warm instance is not enough**, because the service must ride out a restart without a cold request, use 3, as Google suggests, and weigh the cost against an outage.
1. **For a cutover day**, a minimum instance costs cents; our [cutover checklist](https://exodus.elim.io/blog/the-cutover-day-checklist) sets it the week before and removes it after.

## Making the start itself shorter

A shorter start helps every cold start, including the ones a minimum instance cannot prevent. Google's tips:

- **Listen early.** Open the port first; open pools and load caches lazily, on the first request that needs them. The cost, in Google's words, is a slower first such request.
- **Load less.** Fewer and smaller dependencies; in Node.js, bundle the code and load rare modules when needed; in Python, import heavy modules where they are used.
- **Java.** Thin JARs; `-XX:TieredStopAtLevel=1` in `JAVA_TOOL_OPTIONS` to compile less at startup; application class data sharing.
- **Python with gunicorn.** Google's sample runs one worker with 8 threads, `--workers 1 --threads 8`; the [Node, Python, Rails and Go guide](https://exodus.elim.io/blog/node-python-rails-and-go-on-cloud-run) has each stack's container.
- **The execution environment.** The first generation, based on gVisor, has faster cold starts; the second starts slower for some services and runs faster under load. Our [buildpacks or a Dockerfile guide](https://exodus.elim.io/blog/buildpacks-or-a-dockerfile) covers smaller images.

## A keep-warm ping is not the same

A Cloud Scheduler job that calls the service every few minutes often keeps an instance alive, because idle instances may stay up to 15 minutes. It does not guarantee it: Google's container contract says an idle instance "can be shut down at any time". Each ping is also billed at the active rate. A minimum instance is the setting made for this, at the lower idle rate.

## What breaks

- **A minimum instance that does nothing.** A timer or a queue consumer in a minimum instance on request-based billing gets almost no CPU between requests and silently waits.
- **Revision-level minimum with tags.** Every tagged revision keeps its minimum instances running and billed. A month of forgotten preview tags is a month of idle instances.
- **Expecting zero cold starts.** Minimum instances restart, and scale-outs and deploys still start new instances.
- **Exits in the code.** Google warns against code that exits the process in a minimum instance: each exit is a new cold start.
- **Boost off.** It is on by default only when `gcloud` creates a service. Check the annotation on services made other ways.
- **Measuring in the wrong place.** The `request_latencies` metric leaves out startup time, so a dashboard of it can look fine while users wait. Use `startup_latencies` and the request log.
- **A start over 4 minutes.** An instance that does not listen within 4 minutes fails its start, whatever the minimum. Boost and lazy loading help; our health checks guide has the probe settings.

## Checklist

1. List a week of "Starting new instance" lines for each service and read the reasons.
1. Look at `startup_latencies` and, if you can, the first request on each instance in the request log.
1. Check that boost is on, with the `describe` command above; if not, `--cpu-boost`.
1. Make the start shorter: listen first, load lazily, trim dependencies.
1. Only then decide on `--min 1` at the service level, and note the monthly cost: $8.21 to $9.86 for a small instance in a Tier 1 region.
1. Keep background work out of minimum instances on request-based billing.
1. Look at the bill after a month and decide again.

## Where Exodus comes in

The report Exodus builds for a repository says, under "What works differently", that "a copy that starts after a quiet spell answers in about 0.5 to 2 seconds. Startup CPU boost shortens that; one copy kept warm removes it, for a few dollars a month." `exodus check` flags timers inside the process, the code that a minimum instance on request-based billing would not run, and points to Cloud Scheduler. When your coding agent has to decide on minimum instances during a move, it can read this guide through `exodus kb` and `exodus ask`.

## FAQ

### How much does a minimum instance cost on Cloud Run?

On request-based billing in europe-west1, an idle minimum instance of 1 vCPU and 512 MiB costs $9.86 a month, and one of 1 vCPU and 256 MiB $8.21, at list prices of October 12, 2026. On instance-based billing the same instance costs $49.93, because idle time is billed at the full rate.

### Does startup CPU boost cost extra?

Yes, a little. You pay for the boosted CPU during startup and for the 10 seconds after: at most $0.000252 for a 1 vCPU service that starts in half a second. Our 671 starts a month would add at most $0.17. New services created with gcloud get boost by default.

### Does a minimum instance prevent all cold starts?

No. It removes the start from zero to one, but scale-outs and deploys still start new instances, and Google calls the minimum a best-effort target: minimum instances can be restarted at any time. Startup CPU boost and a shorter start help with the rest.

### Can a minimum instance run background jobs?

Not on request-based billing, the default: an idle instance keeps its memory but gets almost no CPU, so a timer or queue consumer inside it waits. Google's advice for work outside requests is instance-based billing with at least one minimum instance; Cloud Scheduler is usually cheaper.

### Is a keep-warm ping cheaper than a minimum instance?

Not reliably. A Cloud Scheduler ping every few minutes often keeps an instance alive, since idle instances may stay up to 15 minutes, but Google says an idle instance can be shut down at any time, and each ping is billed at the active rate.

## Sources

1. [Set minimum instances for services, Cloud Run, Google (instances kept warm even when idle; can be restarted at any time; at least 3 for high availability; a best-effort target with four limitations: zone or region capacity, infrastructure rebalancing, crashing containers, quota and billing limits; request-based billing charges a lower rate while idle, instance-based the default rate; Google recommends service-level over revision-level and not combining them; service-level takes effect without a new revision; revision-level minimum instances start for every revision in a traffic split or with a tag; service-level minimum divided across revisions by the traffic split, rounded, the first-listed revision rounded up; the largest minimum wins and every maximum caps it; requests spread over all minimum instances, and Cloud Run routes to the minimum instances before autoscaled ones; gcloud run services update --min, run.googleapis.com/minScale, autoscaling.knative.dev/minScale, min_instance_count; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/min-instances)
2. [Configure CPU limits for services, Cloud Run, Google (startup CPU boost during instance startup and for 10 seconds after; boosted CPU 2 for a limit of 0 to 1, 4 for 2, 8 for 4, 6 and 8; charged for the boosted CPU for the startup time including the 10 seconds; all containers including sidecars are boosted; gcloud run services update --cpu-boost and --no-cpu-boost; run.googleapis.com/startup-cpu-boost; default 1 vCPU, minimum 0.08; below 1 vCPU concurrency must be 1 and billing request-based; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/services/cpu)
3. [Cloud Run pricing, Google (request-based billing in Tier 1 regions such as europe-west1: CPU $0.000024 per vCPU-second and memory $0.0000025 per GiB-second while active, idle minimum instances $0.0000025 per vCPU-second and $0.0000025 per GiB-second, $0.40 per million requests; idle instances that are not minimum instances are not charged; instance-based billing $0.000018 per vCPU-second and $0.000002 per GiB-second for the whole instance life, at least one minute; billed time rounded up to 100 ms and includes startup and shutdown; free tier 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests a month 'based on us-central1 active pricing', applied as a spending based discount; committed use discount column for request-based services $0.00001992 per vCPU-second active and $0.000002075 idle; read Oct 12, 2026)](https://cloud.google.com/run/pricing)
4. [Compute flexible committed use discounts for Cloud Run, Google (a commitment to an hourly spend for one or three years; 17% for services with request-based billing for either term; 28% and 46% for instance-based services, jobs and worker pools; read Oct 12, 2026)](https://docs.cloud.google.com/run/cud)
5. [About instance autoscaling in Cloud Run services, Google (a revision with no traffic scales to zero unless minimum instances are set; on-demand scaling is the only driver for scaling from zero; scale-in removes instances under 10% busy over a minute first, others stay up to a 15-minute idle timeout, 10 minutes with GPUs; set minimum instances to at least 1 for work outside requests; requests pend up to 3.5 times the average startup time or 10 seconds; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/about-instance-autoscaling)
6. [Container runtime contract, Cloud Run, Google (listen within 4 minutes; requests sent as soon as the container listens; requests pend up to 3.5 times the average startup time or 10 seconds; an idle instance is not kept longer than 15 minutes unless it is a minimum instance; any idle instance, minimum instances included, can be shut down at any time; CPU of an idle instance depends on the billing setting; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/container-contract)
7. [General development tips, Cloud Run, Google (startup is downloading the image with image streaming, running the entrypoint and waiting for the port; startup CPU boost; default maximum concurrency 80; minimum instances of 1 serve up to the configured concurrency without a start; avoid exits that shut a minimum instance down; fewer and smaller dependencies; global variables reused across requests; lazy initialization moves the cost to the first request that needs it; a different execution environment may start faster; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/tips/general)
8. [Java tips, Cloud Run, Google (Google's metrics show Java apps can cut startup time by up to 50% with startup CPU boost; thin JARs; -XX:+TieredCompilation -XX:TieredStopAtLevel=1 through JAVA_TOOL_OPTIONS; application class data sharing; lazy initialization; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/tips/java)
9. [Node.js tips, Cloud Run, Google (bundle the code, lazy load dependencies to shorten startup; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/tips/nodejs)
10. [Python tips, Cloud Run, Google (load only the files needed at startup, import heavy modules when needed; gunicorn --workers 1 --threads 8 --timeout 0; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/tips/python)
11. [New startup CPU boost improves cold starts in Cloud Run, Cloud Functions, Google Cloud blog, Sep 26, 2022 (up to 50% faster for Spring PetClinic, 47% for a native Spring GraalVM service, 23% for a plain Java function; up to 30% for Node.js; minimum instances remove the zero-to-one cold start but not the ones when traffic scales out; read Oct 12, 2026)](https://cloud.google.com/blog/products/serverless/announcing-startup-cpu-boost-for-cloud-run--cloud-functions)
12. [Execution environments, Cloud Run, Google (first generation, based on gVisor, has fast cold starts; second generation performs faster under sustained load and has longer cold starts for some services; services default to unspecified and Cloud Run picks; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/execution-environments)
13. [Optimize with Recommender, Cloud Run, Google (Cloud Run's cost recommendation is a switch from request-based to instance-based billing; no recommendation for minimum instances or startup CPU boost; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/recommender)
14. [Google Cloud metrics, Cloud Monitoring (run.googleapis.com/container/startup_latencies, the time to start a new instance; request_latencies measured without startup latency; container/instance_count by state; container/billable_instance_time; read Oct 12, 2026)](https://docs.cloud.google.com/monitoring/api/metrics_gcp_p_z)
15. [gcloud run services update and gcloud run deploy, Google Cloud SDK (--min for the service, divided among revisions with traffic and changed without a new revision; --min-instances for a revision, set on each new revision; 'default' removes either; --[no-]cpu-boost, enabled by default when unspecified on new services; --scaling for manual scaling; checked against gcloud 587.0.0 help on Oct 12, 2026)](https://docs.cloud.google.com/sdk/gcloud/reference/run/services/update)
16. Exodus team: read-only look at our own project on Oct 12, 2026 (8 services, all with minimum instances 0 and startup CPU boost on, 1 vCPU, 128 to 512 MiB; 671 instance starts in 30 days, 623 for autoscaling and 48 for deploys; start to ready median 0.57 s, p90 0.84 s, p99 1.49 s, max 2.25 s; 18,602 requests, 636 of them the first on a new instance, median latency 0.43 s against 0.002 s for later requests; startup at 1 and 2 CPUs on our build machine with Docker's limit: Spring PetClinic 2.4.5 on Java 8 40.6 s and 20.4 s, a Node.js Express sample 0.70 s and 0.56 s, Docker alone 0.27 s)