UPDATE 22:25 UTC: Google appears to have fixed it. Cold starts are working again (seen i n us-central1) even for functions still on automatic updates. The on-deploy redeploy below is still a valid fallback if it comes back. Outage window seen: about 21:15 to 22:25 UTC.

FIX (confirmed by several people, works immediately): redeploy with the runtime pinned instead of auto-updated. * Cloud Functions gen2: gcloud functions deploy FUNCTION_NAME --gen2 --region REGION --runtime-update-policy=on-deploy --source PATH_TO_BUILT_FUNCTIONS (keeps triggers, secrets and settings)* Cloud Run source deploys: redeploy with --no-automatic-updates * A plain redeploy does not help: it keeps automatic updates on and lands on the same broken runtime.

Script it if you have a lot of functions; it's one deploy per function. Write-up with checks and a one-linerlisting what's still on automatic updates: https://gist.github.com/mrbenji/5da8f50a875b8e0bbb7141bd24caa726

What's happening Reported so far in us-central1, us-east1 and northamerica-northeast1, across many unrelated projects and accounts, since about 21:15 UTC Oct 22. Google's status page shows nothing yet. Support cases are open. * New instances never start. Warm instances keep serving, so it looks intermittent.* Revisions go Ready=False with "The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable within the allocated timeout."* Request logs: "The request failed because the instance could not start successfully." No stdout, stderr or "Starting new instance" line at all.* Firebase callables show up in the browser as CORS errors (the OPTIONS preflight returns 500). Scheduled and Firestore-triggered functions fail too. Repro without any app code

A minimal Node http server fails with automatic base image updates and works without them:

``` gcloud run deploy probe --source . \ --base-image us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/nodejs22 \ --automatic-updates # fails the startup probe

same command with --no-automatic-updates: deploys and serves

```

Google's plain hello sample image runs fine in the same project. New nodejs22 base images were published Oct 22 (nodejs22_20261022, Node 22.23.4), which is my best guess for the trigger.

Afterwards: Firestore-triggered functions without retries drop the events that failed, so plan a backfill for anything that ran during the outage.

Since about 21:15 UTC today (Oct 22), none of my 2nd-gen Cloud Functions in us-central1 can start a new instance.

What I'm seeing:

- Instances that were already warm keep serving fine.

- Anything that needs a NEW instance gets an instant HTTP 500 (0s latency), with no "Starting new instance" line in the logs.

- Scheduled functions fail too (Cloud Scheduler run returned 500).

- Redeploying doesn't help: deploys fail with "Container Healthcheck failed ... failed to start and listen on PORT=8080", and the container logs nothing at all, so it never actually runs.

Ruled out:

- Affects 15+ projects across two separate Google accounts and four billing accounts, with and without an org, so not a project setting.

- No quota-exceeded events, billing active everywhere, no config/IAM changes.

- Reproduces from two different networks.

Nothing on the Google Cloud or Firebase status pages yet. Support case is open.

If you're on us-central1 with Functions or Cloud Run, can you check whether a cold start works for you? Even a "mine's fine" helps narrow it down.

We benchmarked two identical e2-micro VMs side by side (2 shared vCPUs, 1 GB RAM, 2 GB swap, Ubuntu 24.04, same region): the old build of our agent runner on one, the new build on the other, every wave started on both in the same second, so the difference is the code, not the cloud.

Each agent was a real session doing a small job: search a repo, read one file, write a bug report. The model calls go to Gemini through Google's API; the VM runs the sessions, tools and disk writes.

Results on the new build:

- 100 agents: 23 s (was 42 s), no swap

- 150 agents: 51 s, no swap

- 200 agents: all finished, with the machine at its limit

The bottleneck wasn't CPU or the network. It was lock contention in our own save path: every save took one account-wide lock. Per-session locks, releasing the lock before waiting on the disk, and a session cache brought total lock wait from 1,422 s to 61 s, and disk writes from 344 MB to 149 MB.

Disclosure: I work on Swarm (open source).

Which AWS, GCP, or Azure resellers can provide access to AI services? I am looking to establish a partnership.

my email [xiaoshizi528@gmail.com](mailto:xiaoshizi528@gmail.com)

Hello Everyone,

Is there anyone here, who is a representative and/or working officially for Google Cloud?

Can someone tell me from experience, in approximately how many business days do you get a reply for your statements and requests?

Thanks and best regards,

T.

I created an explainer video about google cloud's London outage in my youtube with the help of claude. I like to get your ideas and suggestions.

https://youtu.be/u0MG_eI1c_8