Railway runs on Google Cloud, AWS, and its own metal.

So when I first saw that Railway was down for hours, my first thought was probably the same as yours.

“How does a multi cloud platform go dark like that?”

Then I read the incident report, the Hacker News discussion, and the follow up coverage. And the real lesson is uncomfortable.

This was not really a cloud outage.

The servers did not all die. AWS did not die. Railway Metal did not die. Google Cloud infrastructure itself did not have to collapse.

What failed was much higher up the stack.

The account.

Google Cloud placed Railway’s production account into suspended status incorrectly as part of an automated action. Railway says this happened around 22:20 UTC on May 19, and the platform was not fully recovered until the next morning. (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage)

That should make every CloudOps, platform, SRE, and engineering leader stop for a minute.

Because most redundancy plans are built for the wrong failure.

We design for dead VMs.
We design for unavailable zones.
We design for regional failover.
We design for database replicas.

But what do we do when the provider says, incorrectly or automatically, “your account is no longer allowed to exist normally”?

Not much, usually.

1. This was not a cloud outage. It was an account suspension

That is the first big lesson.

A lot of people hear “cloud outage” and instantly think of regions, zones, load balancers, or broken hardware. But Railway’s case was different.

Google Cloud’s automated systems suspended Railway’s production account. Railway says this was incorrect, and that the action was part of a wider automated event affecting many accounts. (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage)

That kind of failure does not look like a server going unhealthy.

It looks like identity, billing, trust, abuse detection, policy, support, and account control all becoming part of your availability story.

Your health checks can say everything is fine.

Your multi zone architecture can be green.

Your workloads can still technically exist.

But if the account is restricted, your beautiful infrastructure diagram does not matter much.

This is the part many teams do not model.

They model “what if eu west 1 is down?”

They rarely model “what if our production cloud account is frozen by an automated system at 11 PM?”

And honestly, that second one is scarier.

Because you do not debug it with kubectl.

You debug it with support tickets, escalation paths, account managers, legal trust, and luck.

2. The control plane was the real single point of failure

Railway had workloads on AWS and Railway Metal that were still running during the incident. But users still saw errors.

Why?

Because the routing control plane was hosted on Google Cloud.

Railway’s edge proxies needed that control plane to know where workloads lived. They had cached route data for a while, but once the cache expired, the edge could not keep routing properly. Railway’s community update said route cache expiry caused the incident to spread beyond GCP hosted workloads and affect the wider platform. (https://station.railway.com/community/what-we-know-so-far-may-19th-2026-86354cdd)

This is the second lesson.

Your data plane can be redundant while your control plane is still fragile.

And this is where a lot of “multi cloud” thinking becomes a little fake.

You can run compute in three places.
You can run storage in two places.
You can have Kubernetes clusters everywhere.

But if the scheduler, routing map, identity service, deployment API, config database, or certificate automation lives in one provider, your multi cloud story may only be multi cloud on paper.

The thing customers see as “the product” is often not the workload.

It is the control plane around the workload.

For Railway, customers were not just buying raw compute. They were buying routing, builds, deployments, dashboard access, APIs, orchestration and platform magic.

And the platform magic had a dependency.

That dependency became the outage.

3. Getting the account back is not the same as getting the service back

This one is very important.

According to Railway, Google reversed the suspension shortly after escalation. But recovery still took hours because account restoration did not automatically bring everything back cleanly. Persistent disks, compute instances, networking and orchestration layers had to be restored and verified step by step. (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage)

This is the part people underestimate.

A provider can say, “access restored.”

But your system still has to wake up.

Disks need to attach.
Networks need to behave.
Queues need to drain.
Deployments need to stop stampeding.
Databases need to agree again.
Caches need to be repopulated.
Humans need to verify what is safe.

That is not instant.

And in a complex platform, bringing things back too fast can be worse than bringing them back slowly.

Railway also throttled queued deploys during recovery, which sounds boring, but it is actually the responsible move. Because after an outage, your own backlog becomes traffic. And that traffic can flatten the recovering system.

So the real RTO is not:

“How fast can the provider undo the mistake?”

It is:

“How fast can we safely restore the whole chain after the provider undo the mistake?”

Small difference in words.

Huge difference in reality.

4. Recovery can create a second outage

This is probably my favorite lesson from the whole incident, because it is so real.

When Railway started recovering, queued retries and user activity came back in a burst. That burst hit GitHub OAuth and webhook flows hard enough that GitHub rate limited Railway. So logins and builds had problems again, even after the original Google Cloud issue was no longer the main blocker. (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage)

That is painful.

The first outage came from one provider.

The second problem appeared during recovery, from another dependency.

This happens more often than teams admit.

After an outage, everything tries to catch up.

Cron jobs wake up.
Webhooks retry.
CI pipelines restart.
Users refresh dashboards.
Workers pull old messages.
Integrations suddenly see a wall of traffic.

And then some other system says, “this looks abusive.”

Now your recovery has become its own incident.

This is why serious resilience is not just failover.

It is controlled recovery.

Backpressure matters.
Retry budgets matter.
Queue draining matters.
Circuit breakers matter.
Rate limit awareness matters.
Runbooks matter.

And boring old institutional memory matters even more.

Railway had already hardened parts of the GitHub rate limit path after a prior incident, which helped reduce damage this time. That is not luck. That is the value of learning properly from past pain.

5. Most teams insure the wrong half of the risk

The Railway incident is not the first time account level cloud risk became real.

In 2024, UniSuper, a major Australian pension fund, had a serious Google Cloud incident where its private cloud environment was deleted because of a misconfiguration. Google later published details saying backups in Google Cloud Storage and third party backup software helped restoration. (https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident)

So no, account level and provider control plane risk is not some imaginary edge case.

It happens.

But most companies still talk about redundancy like this:

“We use multiple clouds.”

Ok, but what does that mean?

Does it mean workloads can run somewhere else?

Or does it mean you can actually operate the business if one provider account disappears?

Those are very different things.

Flexera’s 2026 State of the Cloud report shows multi cloud is still a major enterprise pattern, and its report is based on 753 cloud decision makers. (https://info.flexera.com/CM-REPORT-State-of-the-Cloud?lead_source=Organic+Search) But in practice, many companies are multi cloud for procurement, politics, analytics, or workload placement.

Not always for true survivability.

True survivability asks much harder questions.

Can we deploy without this provider?
Can we route without this provider?
Can we authenticate without this provider?
Can we restore backups without this provider?
Can we contact support fast enough?
Can we prove ownership if an automated trust system flags us?
Can we keep serving read only traffic if the control plane dies?
Can we rebuild from another account, another org, or another provider?

That is not as sexy as “active active multi cloud.”

But it is probably more useful.

The real takeaway

Railway did have redundancy.

Just not for the layer that failed.

And that is the uncomfortable lesson for the rest of us.

Redundancy at the compute layer does not protect you from account suspension.

Multi region databases do not protect you from provider level identity actions.

Healthy servers do not help when routing control planes cannot tell traffic where to go.

And getting your cloud account back does not mean your service is back.

The next resilience review should not only ask:

“What happens if a region dies?”

It should also ask:

“What happens if our cloud provider suspends our production account by mistake tonight?”

This series of post will try to explain a complex topic: concurrent and parallel programming, in Dart. I think the only way to deal with that is using the Erlang VM (BEAM), but Clojure and other functional languages are usually doing better job on this part. Unfortunately, to me, most of other languages using OOP don’t offer a great abstraction to concurrency and parallelism, but during the last decade, things are changing a bit.

Anyway, before talking about concurrency, parallelism, or even distributed systems, everything starts with synchronous call, the “standard” way to execute a function or a procedure on a computer. In dart, synchronous function call and generators functions need to me studied a little bit.

Firstly, all function without any specific keyword are all defined as synchronous:

int addition(int x, int y) {
  return x + y;
}

If the keyword sync was present in the language, the previous snippet would be equivalent to the one below. Don’t try to compile it, it will fail.

// could be equivalent to the following
// snippet with the sync keyword. But this
// function will not work, sync keyword is
// invalid during compilation
int addition_sync(int x, int y) sync {
  return x + y;
}

When adding the addition() function inside the main() entry-point, it will directly return the value. In fact, you can’t really see this because it’s quick, but the computer will block a little bit to wait the result of the computation.

int main() {
  return addition(1, 2);
}

A synchronous function will always wait for any kind of return before continuing the execution of the program. For example, if an infinite loop is created, the function will never return, and the function will block the whole program. The following snippet, when executed, will never return because of the while loop defined in the infinite_loop() function. The only way to close this program is to kill it (for example using Ctrl-C or sending another signal on UNIX systems).

int infinite_loop() {
  while (true) {
    // do something
  }
  return 0;
}

int main() {
  return infinite_loop();
}

Great, we know how to create synchronous functions. Now, let have a look on a specific keyword: sync*. This one is a syntactic sugar to help developers creating generators, a function that return many elements, one at a time. The best example is the List class (or []). This data type – a list – is seen as a generator, and more precisely an Iterable.

A function is a generator if its body is marked with the sync* or async* modifier. […] Generator functions are a sugar for functions that produce collections in a systematic way, by lazily applying a function that generates individual elements of a collection. Dart provides such a sugar in both the synchronous case, where one returns an iterable, and in the asynchronous case, where one returns a stream.

— Dart Language Specification, Chapter 9, page 23

Let create our first generator from scratch, let call it int_generator(). It will take 2 integers as arguments and will return the list of elements between them. You can see it as a kind of primitive range or sequence function.

Iterable<int> int_generator(int x, int y) sync* {
  if (y<x) throw "y<x"; 
  while (x <= y) {
    yield x;
    x++;
  }
}

int main() {
  for (var i in int_generator(0, 10)) {
    print(i);
  }
  return 0;
}

In the first place, instead of returning a simple int this function is returning an Iterable<int>. Why? Because we are using yield, but we will explain that a bit later. Next, the function definition looks like a classic one, but the sync* keyword is added just after. It means this function will be a generator.

Then, the body of the function where a first step is to avoid creating an infinite loop by creating a simple guard throwing an exception if the second argument is less than the first argument. Immediately after, a while loop is created, where the first argument is incremented until the first argument is less or equal to the second one.

The yield statement adds an object to the result of a generator function.

— Dart Language Specification, Chapter 18, Section 16, page 213

In this loop, the keyword yield followed by variable (or any valid terms) is used. This specific expression is important, because it will adds the object into the result of the generator. In other words, if another function is calling the previous function inside a loop, the sequence of integer will be printed to the screen.

Let execute that from the console.

$ dart run bin/int_generator.dart
0
1
2
3
4
5
6
7
8
9
10

yield is not the only unique term here able to put an object inside a generator, yield* (yield-each) can also be used to push a series of objects, in fact a subtype of Iterable class.

The yield-each statement adds a series of objects to the result of a generator function.

— Dart Language Specification, Chapter 18, Section 17, page 214

Iterable<int> int_generator(int x, int y) sync* {
  if (y<x) throw "y<x"; 
  yield* [x,y];
}

int main() {
  print(int_generator(0, 10));
  for (var i in int_generator(0, 10)) {
    print(i);
  }
  return 0;
}

Let execute this code.

$ dart run bin/int_each_generator.dart 
(0, 10)
0
10

To be honest, I don’t currently understand why it returns a record on the first part of the program. I was reading the specification but I was unable to find and answer. I will let this problem for future-me. A quick note though: a generator cannot return a value.

Case ⟨Generator functions⟩. It is a compile-time error if a return statement of the form return e; appears in a generator function.

— Dart Language Specification, Chapter 18, Section 12, page 211

Based on the documentation, it also seems yield* can be used to improve recursive function performance. Here the one of the previous example implemented using recursive function call.

Iterable<int> int_rec_generator(int x, int y) sync* {
  if (x<=y) {
    yield x;
    yield* int_rec_generator(x+1, y);
  }
}

int main() {
  print(int_rec_generator(0, 10));
  return 0;
}

Let run it now.

$ dart run bin/int_recursive_generator.dart 
(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

Same result than before, but it was using a recursive function. If I remember correctly, calling recursively a function in Dart with tail queue optimization and trampoline is a very bad idea (it will consume a lot of stack and memory). Anyway, let switch to another topic: Iterable class.

Iterable class

We know how to create generators, and then Iterable from scratch, but what we can do with this kind of objects? Let read the definition from the API documentation.

A collection of values, or “elements”, that can be accessed sequentially.

— Dart Language Documentation, Iterable class

Not all features will be illustrated there, only the one looking interesting and useful for my own use cases.

• Iterate.generate() constructor creates a new Iterable object using Integer by default (like a Range/Sequence). The second argument offers a way to change the type returned based on the integer sequence produced (a bit like a map()).

int main() {
  var x = Iterable.generate(10);
  print("generate(10): $x");

  var y = Iterable.generate(26, (int x) => String.fromCharCode(x+65));
  print("generate(10, _): $y");

  return 0;
}

$ dart run bin/t.dart 
generate(10): (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
generate(10, _): (A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z)

• Iterable.contains() method returns true if the object passed in the first argument is present in the collection of objects managed by the Iterable.

$ cat bin/contains.dart 
void main() {
  var a = Iterable.generate(26, (int x) => String.fromCharCode(x+65));
  print('"A"? ${a.contains("A")}');
  print('65? ${a.contains(65)}');
}

$ dart bin/contains.dart 
"A"? true
65? false

• Iterable.elementAt() method returns the element present at the position defined by the first argument. If the position does not exist, it throws a RangeError exception.

$ cat bin/elementAt.dart 
void main() {
  var x = Iterable.generate(10);
  print(x.elementAt(0));
  print(x.elementAt(9));
  print(x.elementAt(1024));
}

$ dart bin/elementAt.dart 
0
9
Unhandled exception:
RangeError (index): Index out of range: index should be less than 10: 1024
#0      IndexError.check (dart:core/errors.dart:520:7)
#1      _GeneratorIterable.elementAt (dart:core/iterable.dart:928:16)
#2      main (file:///dart/t/bin/elementAt.dart:5:11)
#3      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:314:19)
#4      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:193:12)

• Iterable.every() method returns true if the collection of items satisfies the anonymous function passed in argument.

$ cat bin/every.dart 
void main() {
  var x = Iterable.generate(10);
  print(x.every((y) => y >= 0 ));
  print(x.every((y) => y == String ));
}

$ dart bin/every.dart 
true
false

• Iterable.fold() method reduces the collection of items using a combine function present in second argument and an initial value defined in the first argument.

void main() {
  Iterable<int> i = Iterable.generate(10);
  print(i.fold<int>(1, (v, e) => v + e));

  var s = Iterable.generate(26, (int x) => String.fromCharCode(x+65));
  print(s.fold<String>("string: ", (v, e) => "${v} ${e}"));
}

$ dart bin/fold.dart 
46
string:  A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

• Iterable.forEach() method iterates of the collection of item. This method returns nothing.

void main() {
  var list = [1,2,3,4, "end"];
  list.forEach((x) => print(x));
}

$ dart bin/forEach.dart 
1
2
3
4
end

• Iterable.join() method joins the collection of item with a String and converts all object in the collection t String.

void main() {
  var list = ["start", 1, 2, 3, "end"];
  print(list.join(", "));
}

$ dart bin/join.dart 
start, 1, 2, 3, end

• Iterable.map() method modifies each element of the collection by calling a function defined in the first argument.

void main() {
  var m = [
    {'a': 1},
    {'b': 2}
  ];
  print(
    m.map(
      (x) => {x.values.first: x.keys.first}
    )
  );
}

$ dart bin/map.dart 
({1: a}, {2: b})

•  Iterable.reduce() methods is similar to Iterable.fold() excepts it does not have an initial value defined.

void main() {
  Iterable<int> list = Iterable.generate(20);
  print(list.reduce((a, e) {
    print("$a $e");
    if (e%2==0) {
      return a + e;
    }
    else {
      return a;
    }
  }));
}

$ dart bin/reduce.dart 
0 1
0 2
2 3
2 4
6 5
6 6
12 7
12 8
20 9
20 10
30 11
30 12
42 13
42 14
56 15
56 16
72 17
72 18
90 19
90

Way more methods are available, but it was not expected to go so deep in this post. If you want to go even deeper, you will need to read the test cases and the Dart implementation:

• Iterable test cases can be found in the files tests/corelib/iterable*.dart from Dart SDK.

• Iterable implementation source code can be found in sdk/lib/core/iterable.dart.

With these 2 links, you will have more than enough to understand how things are working.

Cover Image by Will H McMahan on Unsplash