Cloud / Google Cloud Run Functions Interview questions

Cloud Run functions is Google Cloud's serverless functions-as-a-service offering. You write a single-purpose function, deploy it, and Google runs it on demand without you managing servers, operating systems, or scaling.

It is the current name for what used to be Cloud Functions (2nd gen). Under the hood each function is deployed as a Cloud Run service, built with Cloud Build and triggered either by an HTTP request or by an event routed through Eventarc.

You pay only while the function is handling requests (plus any minimum instances you configure), and it scales to zero when idle.

Cloud Run functions supports two trigger types: HTTP triggers and event-driven triggers.

An HTTP function responds to HTTP(S) requests and gets a run.app URL automatically. It suits webhooks, REST endpoints, and callbacks from Stripe, GitHub, or Slack.

An event-driven function (also called a CloudEvent function) reacts to something happening inside your Google Cloud project, such as a file landing in Cloud Storage or a message arriving on Pub/Sub. All event-driven functions get their events through Eventarc.

Cloud Run functions offers Google-managed runtimes for Node.js, Python, Go, Java, Ruby, PHP, and .NET.

Each runtime bundles an operating system image, language support, and the Functions Framework library that actually invokes your code. Runtimes are identified by a language-and-version ID such as python312 or nodejs22, which you pass at deploy time.

Every runtime follows a support schedule, so deprecated versions eventually stop accepting new deployments. Check the current runtime list before picking a version.

Pick the language your team already knows well. No single runtime is the fastest choice for every workload.

The Functions Framework is an open-source library, available per language, that wraps your function in a small HTTP server and routes incoming requests or CloudEvents to it.

It is what the managed runtimes use to call your code. Because it is open source, you can run the same function on your laptop, in Docker, or on another platform, which makes local testing simple.

pip install functions-framework
functions-framework --target=hello_http --port=8080

The --target flag names the function to expose.

Because it runs the same code path as production, it catches routing and signature mistakes before you deploy.

An HTTP function is a function that runs in response to an HTTP(S) request. Deploying one automatically provisions a run.app HTTPS endpoint, so no load balancer or routing config is needed.

It receives the request object and must send a response. The caller stays connected until the function returns, so the function has to finish within the configured timeout.

import functions_framework

@functions_framework.http
def hello_http(request):
    name = request.args.get("name", "world")
    return f"Hello {name}!", 200

An unhandled exception in an HTTP function returns a 500 to the caller, so wrap risky calls and return clear status codes for bad input.

An event-driven function runs in response to an event from a Google Cloud service, such as an object finalized in Cloud Storage, a Pub/Sub message, or a Firestore write. The event is delivered as a CloudEvent through Eventarc.

Nobody is waiting on a response, so the function does its work and exits. Because delivery is at-least-once, the same event can arrive more than once, which is why these functions should be idempotent.

@functions_framework.cloud_event
def on_upload(cloud_event):
    data = cloud_event.data
    print(f"File: {data['name']} in {data['bucket']}")

Eventarc is Google Cloud's event routing service and Google's implementation of the CloudEvents spec. For Cloud Run functions it is the delivery layer that connects an event source to your function.

It supports events directly from many Google services and, through Cloud Audit Logs, from 90+ sources. It also handles Pub/Sub events and custom events from your own apps.

When you create an event-driven function, you define a trigger with event filters, for example the event type google.cloud.storage.object.v1.finalized and a bucket name. Eventarc then calls the function whenever a match occurs.

A cold start is the extra latency incurred when a request arrives and no warm instance is available, so Google must create a new one. It includes starting the container, booting the runtime, and running your global initialization code.

Warm instances that are already running skip all of that, so repeat requests are noticeably faster.

Cold starts are most visible after idle periods or sudden traffic spikes. Heavy imports, large dependencies, and slow global setup make them worse.

You can see it in Cloud Trace by comparing the first request after an idle period with the ones that follow.

Minimum instances is a setting that keeps a chosen number of instances running even when there is no traffic. The default is 0, which allows true scale-to-zero.

Raising it to 1 or more removes most cold starts for the first requests, since a warm instance is always ready. The trade-off is cost, because you pay for those idle instances.

gcloud functions deploy my-func --gen2 --min-instances=1

A good rule is to use it on latency-sensitive endpoints such as a user-facing API, and leave background event handlers at zero, where a short delay rarely matters.

Maximum instances caps how many instances a function can scale out to. It protects downstream systems, such as a database with a connection limit, from being overwhelmed by a traffic burst.

For 2nd gen HTTP functions the default limit is 100 and it can be raised to 1,000. Once the cap is reached, extra requests are queued briefly and may then be rejected.

gcloud functions deploy my-func --gen2 --max-instances=20

Size it from your slowest dependency. For example, a database that allows 100 connections supports far fewer than 100 instances if each opens several.

The default request timeout is 60 seconds. You can raise or lower it at deploy time using the --timeout flag.

The ceiling depends on the trigger type: up to 60 minutes (3600 s) for HTTP functions and up to 9 minutes (540 s) for event-driven functions.

gcloud functions deploy my-func --gen2 --timeout=300s

When the timeout is hit, the caller receives an HTTP 504.

Pick a value with headroom over your slowest normal run, but not so large that a hung call ties up an instance for an hour. For event-driven functions remember the 9 minute ceiling, and prefer a shorter timeout so retries start sooner.

Concurrency is the number of requests a single function instance can handle at the same time. Cloud Run functions (2nd gen) supports up to 1,000 concurrent requests per instance.

Higher concurrency means fewer instances are needed, fewer cold starts occur, and the bill drops. The catch is that your code must be safe for parallel execution, so shared mutable state needs care.

gcloud functions deploy my-func --gen2 --concurrency=80

Start with the default and tune using load tests. CPU-heavy work often prefers lower concurrency because parallel requests compete for the same cores, while I/O-bound handlers that mostly wait on APIs can use much higher values.

Use gcloud functions deploy with a name, runtime, entry point, source location, and trigger. Run it from the folder containing your code.

gcloud functions deploy hello-http \
  --gen2 \
  --region=us-central1 \
  --runtime=python312 \
  --source=. \
  --entry-point=hello_http \
  --trigger-http \
  --allow-unauthenticated

Behind the scenes, Cloud Build packages the source into a container and deploys it as a Cloud Run service. Leave off --allow-unauthenticated if the endpoint should be private.

A deploy takes a minute or two because the build runs first. You can pass memory, environment variables, and the service account in the same command, so the whole configuration is reproducible from a script instead of console clicks.

Install the Functions Framework, then decorate a function that accepts a Flask request object. In Python, the HTTP function receives a Flask request and returns anything Flask can turn into a response.

import functions_framework
from flask import jsonify

@functions_framework.http
def get_user(request):
    uid = request.args.get("id")
    if not uid:
        return jsonify(error="id required"), 400
    return jsonify(id=uid, active=True)

Put dependencies in requirements.txt beside main.py. The entry point defaults to the function name you point at.

For JSON bodies, use request.get_json(silent=True) so bad input returns None instead of raising, and validate fields before using them. Return an explicit status code so callers can tell client errors from server errors.

Deploy the function with a Pub/Sub topic trigger. The simplest way is the --trigger-topic flag, which wires the topic to your function.

gcloud functions deploy process-orders \
  --gen2 --runtime=nodejs22 --region=us-central1 \
  --source=. --entry-point=processOrder \
  --trigger-topic=orders

Every message published to orders becomes an event. The message payload is base64 encoded inside the CloudEvent, so decode it before use. A failing function can retry delivery if retries are enabled.

Message attributes arrive alongside the payload and are handy for routing. Delivery is at-least-once, so deduplicate on the message ID before doing anything that is not safe to repeat, such as sending an email.

Create an event-driven function with an Eventarc trigger filtered to a bucket and an event type. The usual one is google.cloud.storage.object.v1.finalized, which fires when a new object is fully written.

gcloud functions deploy on-upload \
  --gen2 --runtime=python312 --region=us-central1 \
  --source=. --entry-point=on_upload \
  --trigger-bucket=my-uploads

The bucket must be in the same location as the function. The event carries the bucket and object name, not the file content, so your code reads the object using the Storage client.

Large uploads can fire more than one event, so filter on object name prefixes when only certain files matter. Writing output back into the same bucket without such a filter can trigger the function again and create an infinite loop.

2nd gen is built on Cloud Run and Eventarc, while 1st gen is the original standalone runtime with limited triggers and tuning.

New projects should use 2nd gen, and 1st gen functions should be migrated when practical.

A few settings, such as concurrency above 1 and 60 minute HTTP timeouts, simply are not available in 1st gen. Migration usually means redeploying with 2nd gen settings and re-checking each trigger.

Both run on the same platform, but they differ in what you hand over. With a function you give Google source code and a function name, and it builds the container for you. With Cloud Run you bring your own container image or build one with a buildpack or Dockerfile.

Pick a function for a small single-purpose handler, and Cloud Run when you need a custom runtime or a multi-route service.

A function responds to a request or event and is expected to return quickly. A Cloud Run job runs a task to completion with no request, and can run for much longer.

If an event-driven function keeps hitting the 9-minute limit, a common fix is to have it start a Cloud Run job instead.

Both can be started on a cron schedule from Cloud Scheduler.

App Engine hosts an entire web application with its own runtime, routing, and services. Cloud Run functions hosts one small function bound to a trigger.

App Engine fits long-lived web apps with several handlers and background services. A function fits a focused task such as resizing an uploaded image, reacting to a Pub/Sub message, or answering a webhook.

Functions also scale to zero by default and need no app.yaml. For new greenfield work, Google generally points to Cloud Run and Cloud Run functions over App Engine.

Functions also suit teams that want no infrastructure decisions, since the platform picks the build and serving details for you.

By default a deployed function requires authentication. Only callers with the roles/run.invoker IAM role can call it, and they must send a Google-signed ID token in the Authorization header.

To open it publicly, deploy with --allow-unauthenticated, which grants invoker to allUsers. For private traffic, also restrict ingress to internal sources, and run the function as a least-privilege service account.

gcloud functions add-invoker-policy-binding my-func \
  --region=us-central1 \
  --member="serviceAccount:caller@my-proj.iam.gserviceaccount.com"

Never leave an internal function open just to make testing easier. Use gcloud auth print-identity-token to get a token for manual calls, and grant invoker only to the specific callers that need it, such as a Cloud Scheduler service account.

Store the value in Secret Manager and reference it at deploy time. Never hard-code secrets or keep them in plain environment variables in source control.

You can expose a secret as an environment variable or mount it as a file. The function's service account needs roles/secretmanager.secretAccessor on that secret.

gcloud functions deploy my-func --gen2 \
  --set-secrets 'DB_PASS=db-password:latest'

Using latest picks up rotations on the next instance start, while a pinned version stays fixed.

Secrets mounted as files are read when accessed, while env var secrets are resolved when the instance starts. A pinned version never changes until you redeploy with a new one.

Use --set-env-vars at deploy time, or --env-vars-file to load a YAML file. Variables are available to your code through the standard environment APIs.

gcloud functions deploy my-func --gen2 \
  --set-env-vars=ENV=prod,REGION=us-central1

import os
env = os.environ.get("ENV", "dev")

Use them for non-sensitive config such as feature flags and endpoints. Anything sensitive belongs in Secret Manager.

Variables are set per revision, so changing one means redeploying. Names like K_SERVICE and K_REVISION are set by the platform and should not be overwritten. Keep a clear naming convention, such as APP_ENV and DB_HOST, so the same code runs unchanged across dev, staging, and production.

Functions run outside your VPC by default, so they cannot reach private IPs such as a Cloud SQL private address or an internal service. To fix that, enable Direct VPC egress or attach a Serverless VPC Access connector.

Direct VPC egress is the newer, simpler option because it needs no connector instances. The connector approach still works and is common in older setups.

gcloud functions deploy my-func --gen2 \
  --vpc-connector=my-connector \
  --egress-settings=private-ranges-only

With private-ranges-only, only private traffic goes through the VPC and public calls leave directly.

Whichever option you use, the VPC needs firewall rules and routes that allow the traffic, otherwise connections will simply time out.

Anything your function writes to stdout or stderr is captured by Cloud Logging automatically. You can view it in the console or from the CLI.

gcloud functions logs read my-func --gen2 --region=us-central1 --limit=50

For structured logs, print JSON with a severity field so entries are filterable. Each log entry is linked to the request through a trace ID, which helps when following one call across services.

Avoid logging full request bodies or secrets, because logs are retained and widely readable. Use levels consistently so alerts can target ERROR entries, and add a request or user ID as a field so one failed call can be traced quickly.

Scaling is automatic and driven by incoming load. When requests arrive and existing instances are busy, Cloud Run adds instances. When traffic drops, it removes them, down to zero unless minimum instances is set.

The number of instances needed depends on request rate, how long each request takes, and your concurrency setting. With concurrency 80, one instance can serve 80 simultaneous requests, so you need far fewer instances than with concurrency 1.

Scaling stops at max instances. Beyond that point, requests queue and may eventually fail.

Scale-out is not instant, so a sudden burst can still hit cold starts before enough instances are ready. Minimum instances smooth that out.

Event delivery is at-least-once, so the same event may reach your function more than once. This happens after a retry, a timeout, or a network hiccup. If running the function twice causes harm, such as double-charging a customer, the function is not idempotent.

To make it safe, use the event ID as an idempotency key. Check whether you already processed it before acting.

def handle(cloud_event):
    event_id = cloud_event["id"]
    if already_done(event_id):
        return
    do_work()
    mark_done(event_id)

Use transactions or conditional writes so the check and the mark happen atomically.

Natural keys also work. If the event says order 42 is paid, setting order 42 to paid twice leaves the same result, so no extra check is needed.

Retries are off by default. When you enable them, a failed invocation is retried until it succeeds or the retry window ends. For 2nd gen, that window is 24 hours, with exponential backoff between 10 and 600 seconds.

gcloud functions deploy my-func --gen2 --retry ...

Retries help with transient errors but can loop forever on a bug in your code. To avoid an endless loop, drop events older than a threshold by checking the event timestamp. Pair retries with idempotent code.

Because of the backoff, a function that keeps failing is invoked less and less often as time passes, rather than hammering the failing dependency.

Choose Cloud Run functions when the job is a small, single-purpose handler: reacting to a bucket upload, processing a Pub/Sub message, or answering a simple webhook. You write only the function, and Google handles the packaging.

Choose Cloud Run when you need a custom runtime, system libraries, a multi-route API, or an existing container image.

If you have a function that has outgrown its single handler, you can move it to Cloud Run with little rework because both run on the same platform.

Cost rarely decides it, since both bill on the same usage model. The real question is whether the function packaging gets in your way.

Browsers send a preflight OPTIONS request before cross-origin calls, and your function must answer with the right CORS headers. If it does not, the browser blocks the response.

def api(request):
    headers = {"Access-Control-Allow-Origin": "https://app.example.com"}
    if request.method == "OPTIONS":
        headers.update({
            "Access-Control-Allow-Methods": "GET, POST",
            "Access-Control-Allow-Headers": "Content-Type",
            "Access-Control-Max-Age": "3600"})
        return ("", 204, headers)
    return ({"ok": True}, 200, headers)

Avoid a wildcard origin on authenticated endpoints. Also note that IAM-protected functions reject the preflight unless it is allowed, which is a common surprise.

Set Access-Control-Max-Age so browsers cache the preflight and skip it on later calls. Test from a real browser, because curl will never reveal CORS problems.

Run it with the Functions Framework, which starts a local HTTP server that behaves like the managed runtime.

functions-framework --target=hello_http --port=8080
curl "localhost:8080?name=Ana"

For event-driven functions, send a CloudEvent as an HTTP POST with the right headers, using curl or a test script. For unit tests, call the function directly with a mock request or event object. Emulate dependencies such as Pub/Sub or Firestore with their local emulators where available.

Test with the same language version as production, since small version differences cause surprises. A local run does not enforce IAM or use the real service account, so do a final check in a dev project after deploying.

Each function runs as a runtime service account, and that identity decides what Google Cloud resources your code can access. By default it is the Compute Engine default service account, which often has broad permissions.

Best practice is to create a dedicated service account per function and grant only the roles it needs, such as roles/storage.objectViewer on one bucket.

gcloud functions deploy my-func --gen2 \
  --service-account=fn-reader@my-proj.iam.gserviceaccount.com

The default account often holds broad project roles, so a bug or compromised dependency could modify unrelated resources. Reviewing the roles on each function's account is a quick, high-value security audit for any team.

Use --memory and --cpu at deploy time. In 2nd gen you can go up to 16 GiB of memory and 4 vCPUs.

gcloud functions deploy my-func --gen2 \
  --memory=1Gi --cpu=2

CPU and memory must be in a valid pairing, so more memory may require more CPU. If you see out-of-memory errors or slow CPU-bound work, increase these. Raising CPU can also shorten cold starts for heavy initialization, though it increases cost per second.

Concurrency interacts with these numbers. Ten parallel requests that each need 100 MiB add up to roughly a gigabyte, so memory has to cover peak parallel load, not just a single request.

A CloudEvent is a standard envelope describing an event. It has required attributes plus a data payload.

Your function gets this object and reads data for the details. Use id for idempotency and time to discard stale events.

The trigger defines the event type and the data schema. A Storage event carries a bucket and name, while a Pub/Sub event carries a message with base64 data and attributes, so check the type before parsing.

--entry-point tells Cloud Run functions which function in your source to invoke. A single source file can contain many functions, but only the named one is exposed.

If the value does not match an exported function name, the deploy fails or the container cannot start. In Node.js it matches a registered function name, in Go a registered function, and in Java a fully qualified class name.

gcloud functions deploy hello --gen2 --runtime=python312 \
  --entry-point=hello_http --trigger-http

A mismatch is a common reason a freshly deployed function fails its first startup check. Verify the spelling, and in Python make sure the function sits at the top level of main.py.

When something happens at the event source, Eventarc matches it against your trigger filters, wraps it as a CloudEvent, and sends it to the function's underlying Cloud Run service over HTTP.

The Functions Framework inside the instance parses that request and calls your handler. If the handler returns normally, the delivery counts as successful. If it throws or times out, and retries are on, Eventarc redelivers the event.

sequenceDiagram
  participant S as Event source
  participant E as Eventarc
  participant F as Functions Framework
  participant H as Your handler
  S->>E: Event occurs
  E->>E: Match trigger filters
  E->>F: HTTP POST with CloudEvent
  F->>H: Call handler(cloud_event)
  alt Success
    H-->>F: Return
    F-->>E: 2xx response
  else Error or timeout
    H-->>F: Exception
    F-->>E: Error response
    E->>F: Retry if enabled
  end

Start by attacking what happens at startup, then use platform settings for what remains.

1. Set --min-instances to 1 or more so a warm instance is always ready.
2. Trim dependencies and import heavy libraries lazily, only inside the code path that needs them.
3. Keep global initialization small and avoid blocking network calls at startup.
4. Raise CPU if startup is compute-bound.
5. Increase concurrency so fewer new instances are needed under load.

Measure first. Logs and traces show whether the delay is container start or your own init code.

Cold starts also differ by language. Go and Node.js usually start faster than a large Java application, so factor that in when latency matters. Keep the source small, and make sure startup does not block on a slow dependency.

The caller immediately gets an HTTP 504 response. Any response your code later produces is discarded.

The catch is that the instance is not necessarily killed. It may be throttled but keep running until your code exits by itself. This can make work and log lines from one request appear during a later one, which is confusing to debug.

To avoid it, set a timeout comfortably above your expected runtime, track the time remaining, and return early with cleanup when you are close to the limit.

For example, if a job needs about 90 seconds, set the timeout to 120 seconds rather than leaving 60. If runtime is unpredictable, split the work into smaller pieces that each fit comfortably, and log elapsed time at key steps to see where it goes.

An OOM shows up as the instance being terminated, often with a log line saying the memory limit was exceeded. Start by checking the memory utilization metric in Cloud Monitoring around the failure time.

1. Compare peak usage with the configured --memory value.
2. Check concurrency. Each parallel request adds to the instance's memory use, so lowering concurrency can fix it.
3. Look for large files read fully into memory. Stream them instead.
4. Remember that files written to /tmp live in memory and count toward the limit.
5. Raise memory if the workload genuinely needs it.

After the fix, add an alert on memory utilization above roughly 80 percent so you hear about it before instances start crashing. Heap profiling tools for your language help find leaks when usage climbs request after request.

Code in global scope runs once per instance, not once per request. Creating an expensive object there, like a database pool or a Storage client, lets later requests on the same warm instance reuse it.

from google.cloud import storage
client = storage.Client()   # created once per instance

def handler(request):
    bucket = client.bucket("my-bucket")
    ...

Doing the same inside the handler would rebuild the client on every call, adding latency and wasting connections. The trade-off is that heavy global code lengthens the cold start, so initialize lazily if the object is only used on some paths.

A related trap is storing per-request data in global variables. Since one instance can serve many requests, one user's data may leak into another response, so keep request state inside the handler.

Once an HTTP function returns its response, the request is considered finished and the instance's CPU can be throttled. Threads, timers, or async tasks left running may slow to a crawl or stop entirely until the next request wakes the instance.

So work like sending an email or writing an audit record may never complete, or may complete at a random later time.

Finish everything before returning. For work that really can happen later, publish a message to Pub/Sub or create a Cloud Task, and let a second function handle it with its own retries.

The same applies to unflushed logs or metric buffers. Flush or close them before returning, otherwise the last entries from a request may be lost when CPU is throttled.

Event-driven functions are capped at 9 minutes, so anything longer needs a different shape.

The cleanest fix is to hand the work to a Cloud Run job, which can run up to 24 hours. The function becomes a thin launcher that starts the job and exits.

Another option is to split the work into chunks. The function processes one chunk, then publishes a message for the next, which keeps every invocation short and retryable. For multi-step flows with branching and waiting, use Workflows to coordinate the pieces.

Pass only a reference through the event, such as a file path, not the file itself. The job reads the data directly, which keeps messages small. Log the job execution ID inside the function so you can link the two later.

Every deploy of a 2nd gen function creates a new revision of the underlying Cloud Run service, and earlier revisions are kept. To roll back, point traffic back to the last known good revision.

gcloud run services update-traffic my-func \
  --region=us-central1 \
  --to-revisions=my-func-00012-abc=100

If you cannot find a clean revision, redeploy the previous version of your source from version control. For safer releases, route a small share of traffic to the new revision first, watch error rates, and then shift the rest.

Rollback is fast because the old revision is already built, so no rebuild is needed. After rolling back, check logs from the failed revision to find the cause. Revision tags also let you test a candidate at its own URL without sending it production traffic.

Use the google_cloudfunctions2_function resource. You upload zipped source to a Cloud Storage bucket, then reference it in the function's build config.

resource "google_cloudfunctions2_function" "fn" {
  name     = "hello"
  location = "us-central1"

  build_config {
    runtime     = "python312"
    entry_point = "hello_http"
    source {
      storage_source {
        bucket = google_storage_bucket.src.name
        object = google_storage_bucket_object.zip.name
      }
    }
  }

  service_config {
    max_instance_count = 20
    available_memory   = "512Mi"
    timeout_seconds    = 60
  }
}

Remember to grant invoker access with a separate IAM resource if the endpoint needs to be callable.

Tie the source object name to a content hash so Terraform notices when the code changes and redeploys. Manage the service account and IAM bindings in the same module, which makes the function's access reviewable in a pull request.

A poison message is one that always fails, such as malformed JSON. With retries enabled it will be redelivered over and over until the retry window closes, wasting invocations.

Handle it in code. Catch errors that can never succeed, such as validation failures, log them, and return normally so the message is acknowledged. Send the payload to a separate dead-letter topic or a storage location for review.

Keep real retries only for transient failures, like a timeout calling a downstream API. Also drop events older than a sensible age so a stuck message does not loop for 24 hours.

Tracking error counts by type helps you spot a bad producer. If most failures come from one malformed field, fixing the sender is better than tuning retries.

The caller fetches a Google-signed ID token whose audience is the target function's URL, then sends it as a bearer token. The target verifies it against the roles/run.invoker binding on the caller's service account.

import google.auth.transport.requests
import google.oauth2.id_token
import requests

url = "https://target-abc.a.run.app"
req = google.auth.transport.requests.Request()
token = google.oauth2.id_token.fetch_id_token(req, url)
r = requests.get(url, headers={"Authorization": f"Bearer {token}"})

Inside Google Cloud the token comes from the metadata server, so no key files are needed.

A frequent mistake is mixing audiences, because a token minted for one function's URL is rejected by another. The caller's service account also needs the invoker role on the target, otherwise you get a 403 even with a valid token. For manual tests, gcloud auth print-identity-token gives you a token to use with curl.

Pricing is usage based and follows Cloud Run's model. You are billed for the number of invocations, the compute time (vCPU-seconds and GiB-seconds while handling requests), and network egress. A monthly free tier applies.

Minimum instances add cost because idle warm instances are billed too. Build time in Cloud Build and logging volume are charged separately.

To cut costs, right-size memory and CPU, raise concurrency so one instance serves more requests, and avoid unnecessary min instances. Check the current price list for exact rates, since they change by region.

A function that mostly waits on slow APIs still bills for that waiting time, so tight timeouts and async clients can reduce spend. Compare cost per thousand invocations at your real memory setting instead of guessing.

A common pattern is a Cloud Build trigger on your repository's main branch. Each push runs tests, then deploys with gcloud functions deploy.

steps:
  - name: python:3.12
    entrypoint: bash
    args: ["-c", "pip install -r requirements.txt pytest && pytest"]
  - name: gcr.io/google.com/cloudsdktool/cloud-sdk
    args: ["gcloud", "functions", "deploy", "my-func",
           "--gen2", "--region=us-central1", "--runtime=python312",
           "--source=.", "--entry-point=handler", "--trigger-http"]

GitHub Actions works too using Google's auth action with Workload Identity Federation, which avoids long-lived keys. Give the deploy identity only the roles it needs.

Deploy to a staging project first and run a smoke test against the new URL before promoting. Keep the deploy command in the pipeline rather than typed by hand, so every environment uses identical flags. If the smoke test fails, the pipeline stops and production stays untouched.

Cloud Monitoring collects metrics for the underlying Cloud Run service automatically. The useful ones are request count, request latency, container instance count, and CPU and memory utilization.

Build alerting policies on symptoms users feel: a rising 5xx error ratio, p95 latency above your target, or instance count hitting the max-instances cap. For event-driven functions, also watch the age of the oldest unacknowledged message on the Pub/Sub subscription.

Add a logs-based metric for application errors that do not surface as HTTP codes, and use Cloud Trace to follow a slow request across services.

Send alerts to a channel the team actually watches, and attach a short runbook link to each policy. A dashboard that shows errors, latency, and instance count together makes triage much quicker during an incident.

Chaining functions by having one call another over HTTP spreads logic across code, hides failures, and makes retries hard to reason about. If step 3 fails, nobody knows the state of steps 1 and 2.

Choose Workflows when you have several steps, branching, waiting, or need per-step retries and visible execution history. The workflow calls each function, tracks state, and handles errors in one place.

flowchart LR
  A[Start] --> B["Validate order function"]
  B --> C{Valid?}
  C -- Yes --> D["Charge payment function"]
  C -- No --> G[Reject]
  D --> E["Ship function"]
  E --> F[Done]

For a single trigger and a single action, a plain function is simpler and cheaper.

Workflows also lets you set a retry policy per call and keeps a record of every execution, which simplifies debugging a failed order.