So the solution is the same as it has been for over a decade. Don’t do business with Google.

• scorpioxy

  today at 1:43 AM

  I believe the problem was always the process that Google has where they tend to want to automate everything from the start and make it very difficult to reach a human and explain the situation. The service itself seems solid but if you make it difficult to address any problems when(not if) they occur then I won't be comfortable doing business with you. I stay away from their services for anything serious for this reason and always recommend to others to do the same.

  It's going to be interesting to watch this unfold. Google's automation vs LLM agents, no humans from either side.

• jesterson

  today at 3:02 AM

  > Don’t do business with Google.

  If you think other big tech or bank won't do it for you if you "don't do anything wrong" - you might be delusional.

  The only way to fight it is redundancy. Dont vendor lock in all you stuff in aws/google/cf/whatever. They can (and will) fuck you up at some point.

Identified Google Cloud has blocked our account, making some Railway services unavailable. We have escalated this directly with Google. The Railway Platform team has since confirmed access to Google Cloud and is working on restoring access to all workloads. We have access to some of our Google Cloud–hosted infrastructure and are working to restore the rest of the service. We apologize for the disruption.

Some discussion started an hour ago (12 points, 3 comments) https://news.ycombinator.com/item?id=48200827

The killer isn't "you can get banned" — that risk is known and quantifiable. It's "no human-reachable appeals process and no SLA on resolution." The unknown duration of the outage is what's existential, not the ban.

The mitigation playbook is brutal but well-known: DNS not locked to the vendor, data restorable from off-vendor backups, working credentials with a second provider. Most startups skip it because the math doesn't pencil — until it does, and then they're shutting down within a week.

Railway had a similar reliability issue two weeks ago when an AI agent deleted a customer's production database via their API — no confirmation step, no environment scoping. Now this. Both incidents suggest the same pattern: infrastructure decisions made without thinking through failure modes, fixed reactively after damage is done.

• choilive

  today at 1:48 AM

  I wouldn't blame that incident on Railway.. you can delete your prod database on AWS just as easily with their API.

  • sikozu

    today at 2:07 AM

    That incident wasn't Railways fault at all. Don't use AI in your staging and prod tools.

  • jesterson

    today at 3:04 AM

    If everyone can delete your prod database via API or by any other means - you need to sack CTO without severance package.