Railway Security Incident → ₹17,000 Google Cloud Bill for ₹200 Monthly Usage. What Do I Do?

My usual Google Cloud Gemini API bill was around ₹200 per month. Now, suddenly, I am facing a bill of approximately ₹17,000.

Here is what happened:

• I stored my Gemini API key in Railway environment variables. • Railway recently announced a security incident involving potential exposure of customer credentials. • My API usage suddenly increased from around ₹200 to ₹17,000. • Google Cloud has now suspended my Gemini API project due to suspected abusive activity.

I never knowingly used my API to this extent. I am seriously concerned that my key may have been compromised and used by someone else.

The worst part? My payment was linked to an automatic payment mandate, so I am worried about the money being deducted.

₹17,000 is not a small amount for me. Why should I bear the financial consequences of usage I may never have initiated?

I have trusted these platforms with my credentials, and now I am stuck dealing with a massive unexpected bill and a suspended project.

I have submitted a request to Google Cloud to investigate the usage and review the charges. I also want Railway to investigate whether this incident could have exposed my credentials.

Has anyone experienced something similar with Railway and Google Cloud?

Can Google waive or refund charges resulting from unauthorized API usage?

How can I prevent the automatic payment from going through while this is investigated?

Has anyone successfully disputed a bill like this?

Any advice from people who have dealt with Google Cloud billing disputes would be appreciated.

I am looking for a fair resolution, not trying to avoid legitimate charges.

TL;DR: Normal bill ₹200/month. Unexpected bill ₹17,000. Railway disclosed a possible credential exposure incident. Google suspended my project. I need help disputing the charges and securing my account.

On July 15, 2026, I received an official Google Cloud welcome email stating that I had 30 days to try Gemini Enterprise Business at no cost, with up to five licenses. I signed up only to explore the product, and there was a single actual user.

On July 26, eleven days into the advertised free-trial period, Google Cloud charged my card USD 100.

I opened Billing Support case #73733543. On July 27, Google Cloud Support confirmed in writing that it had processed a USD 100 refund to my original payment method and that it would appear within two to three business days.

The money never arrived. On August 5, Google Payments notified me that an attempted refund of USD 98.81 had failed. Google never explained why the attempted amount was USD 98.81 rather than the promised USD 100.

Instead of retrying the refund or asking for an alternative payment method, Google later stated that the failed refund had been converted into internal service credit and applied to disputed Google charges. My internal balance became zero, but the original USD 100 never returned to my card or to my funds.

After many exchanges, Google Cloud Support issued a final refusal to make a monetary payment because the internal credit had already been consumed. The subscription is now canceled and Google says there will be no future charges, but that does not return the money that was charged.

I have retained the free-trial email, the card transaction, the written refund promise, the failed-refund notice and the later refusals. I am sharing this so that other users document free trials carefully, verify seat counts and monitor their card transactions from day one.

My request remains straightforward: return the USD 100 through the original payment method or another verifiable method. I am not asking for Google Cloud credit.

If a Google Cloud escalation manager can review this, the support case is #73733543.

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

Hello, I have the GCP Professional Data Engineer exam in 2 days.
I studied on GCP Study Hub, and solved every exam on SkillCertPro

Any recommendation for further study and preparation would be highly appreciated!

I think this might be related to the post from yesterday about Vertex AI capacity in the eu multi-region, but we’re consuming via Gemini Enterprise (formally Agent Space).

It’s gradually got worse over this morning, but as of about 10am, we’d get nothing but timeouts or users just sat with “Working on it…” for ~20 mins, specifically for any chat with a context over about 250K tokens.

<250K tokens and it’s slow but usable.

I’ve got a P1 open with Google Support to see if they’ll officially acknowledge an issue, but I wanted to know. Anyone else seeing this?

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.

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.