Cloud Run Functions Costs: What Bills and What Helps

First, the naming

Google’s version comparison explains the change. What was Cloud Functions (2nd gen) is now Cloud Run functions, deployed as a service on Cloud Run and manageable through either the Cloud Run Admin API or the Cloud Functions v2 API. The original product is now Cloud Run functions (1st gen).

This matters for cost because the two generations are priced differently. Google’s functions pricing page points current Cloud Run functions to Cloud Run pricing, and 1st gen functions to their own legacy price list.

What a function costs you

For a current-generation function, the Cloud Run rules apply. There is no instance to stop and no nightly schedule to attach, because an idle function with no minimum instances scales to zero on its own. What keeps billing when nothing happens:

• Minimum instances. Cloud Run keeps that many instances running even when they are not processing requests, and Google states they incur billing costs. The default is 0.
• Instance-based billing, if chosen, which charges for the whole instance lifecycle rather than only request processing (billing settings).

When the function is busy, the Cloud Run pricing page meters vCPU-seconds and GiB-seconds of billed instance time, plus a per-request charge under request-based billing. An oversized memory setting on a hot path is therefore paid on every second of every call.

Levers in practice

1. Audit functions with minimum instances above 0 and ask whether the cold-start protection is worth an always-on charge.
2. Keep request-based billing unless the function needs CPU outside a request.
3. Right-size memory from observed usage on high-volume functions.
4. Migrate 1st gen functions deliberately, pricing both models first, rather than assuming the new one is cheaper.

Where ZopNight fits

ZopNight discovers functions as GCP resources, with their own entry on the Cloud Run functions fact sheet. Functions are not on ZopNight’s start/stop list, and the recommendation catalog has no function-specific rules today, so the value here is cost visibility rather than automated action.

In practice that means function spend shows in cost reports by account, resource type and team, any discovered function can carry its own budget with threshold alerts, and a sudden jump in invocation cost surfaces through daily anomaly detection with a root-cause note. For services deployed directly on Cloud Run, ZopNight does run min-instance rules; see Cloud Run. Background reading on the pattern: serverless cost pitfalls.