Cloud Functions for Firebase Cost: Invocations and Instances

A function bill is not determined by invocation count alone. Model monthly invocations together with average execution time and the CPU and memory allocated to each function. Database triggers, scheduled jobs, retries, and duplicate events can create billable executions even when they do not correspond to a user request.

Separate short API handlers from image processing, exports, and AI orchestration because their duration and resource needs differ. Use production metrics for invocation count, execution time, and memory use, then confirm current included usage and rates on the official Cloud Run functions pricing page.

Minimum instances can reduce cold starts, but warm instances can incur a baseline cost while idle. Apply them only to latency-sensitive functions, choose the smallest practical memory allocation, and estimate the full number of hours each configured instance remains available during the month.

For 2nd gen callable and HTTP functions, concurrency lets one instance serve multiple requests at the same time. Test safe concurrency for the workload and cap maximum instances when protecting a database or third-party API is more important than absorbing every traffic spike.

Cross-region calls and outbound data can add networking charges, so place functions near the Firebase services they use and count response payloads, external API traffic, and generated media. Event-driven functions should be idempotent because automatic retries can repeat both compute work and downstream writes.

Deployments also create container images that use Artifact Registry storage. Set a cleanup policy for old artifacts, review function and billing metrics after each release, and compare a normal month with a traffic-spike scenario before deciding whether always-warm capacity is worth the fixed cost.