Generated by Codex with GPT-5

The Pragmatic Engineer surfaced this May 20, 2026 article, and the original post is Google Cloud deletes Australian trading fund’s infra.

A backup outside the blast radius

The story is alarming because the failure was not a familiar cloud outage. It was not a data center burning down, a region going dark, or a bad deploy taking one product offline. According to The Pragmatic Engineer’s recap, Google Cloud accidentally deleted UniSuper’s cloud subscription, and that administrative mistake removed the data associated with it. UniSuper had replicated across two Google Cloud regions, but the replica lived inside the same provider-level blast radius, so it disappeared too.

UniSuper is not a small customer with a hobby workload. It is a major Australian superannuation fund serving about 615,000 members and managing roughly 124 billion dollars in assets. Its members could not log in or manage accounts for about two weeks, from April 29 to May 15. The fund avoided permanent data loss only because it had a backup with another service provider outside Google Cloud.

That is the sharp lesson. Regional replication protects against regional failure. It does not necessarily protect against account deletion, subscription corruption, identity-system mistakes, billing holds, provider-side abuse flags, or any other control-plane action that can reach across all regions at once. A cloud account is not just an operating environment. It is also an administrative boundary, a billing boundary, an identity boundary, and sometimes a single point of organizational failure.

The control plane is part of production

Many engineering teams reason about reliability by thinking in terms of compute, storage, regions, and traffic routing. That is necessary, but the UniSuper incident shows why it is incomplete. The most important failure domain was not the infrastructure running the workload. It was the authority that could delete or disable the workload.

That authority sits in the cloud control plane. It includes subscriptions, projects, IAM, billing, provider operations, support workflows, and internal tools that customers never see. Those systems are usually treated as dependable background machinery. Most of the time they are. But when they fail, they can fail with more privilege than an application bug.

The Pragmatic Engineer also ties the old UniSuper case to a newer May 2026 incident in which Railway said Google Cloud blocked its account. The details differ, but the reliability pattern rhymes: a provider-level action can remove access to infrastructure even when the application itself is not the failing component. For infrastructure companies and their customers, that kind of failure is especially uncomfortable because it turns “our stack is healthy” into an incomplete answer.

The lesson is not that every team should flee Google Cloud, or any other cloud. The same class of risk can exist anywhere a provider controls the substrate. The point is that cloud reliability is partly a governance and dependency problem, not only an availability-engineering problem. The system is not fully resilient if the provider’s account machinery can make every region irrelevant.

Replication is not backup

The most useful distinction in the article is between replication and independent recovery. Replication keeps a service available when an expected component fails. Backup preserves recoverability when the current system state becomes wrong, corrupt, inaccessible, or deleted.

That difference matters because replication can faithfully copy disaster. If deletion, corruption, or bad permissions propagate across replicas, the replicated system may become consistently unavailable or consistently empty. A backup needs different properties: isolation, retention, testable restore paths, and enough independence from the primary environment that it can survive the primary environment’s failure.

For critical systems, “independent” should be interpreted concretely. Backups that depend on the same cloud account, same identity provider, same billing relationship, same admin group, or same automation pipeline may be less independent than they look. A good backup strategy asks what would still be reachable if the primary cloud account vanished, support access stalled, or the provider temporarily refused to serve the account.

This does not mean every workload needs a full active-active multi-cloud architecture. That is expensive, operationally complex, and often unjustified. But the UniSuper case makes a much narrower case that is hard to dismiss: valuable data should have a recovery path outside the administrative domain that can destroy or block the live system.

The business impact is trust

The technical recovery was only part of the damage. UniSuper’s funds were reportedly safe, and the fund came back because it had off-provider backups. But hundreds of thousands of members spent days unable to see or manage retirement accounts. For a financial institution, that is a trust event, not merely an uptime event.

Google Cloud also took public responsibility through a joint statement with UniSuper. That is unusual, and it makes the incident more useful as a case study. Providers rarely accept blame so cleanly in major outages, because root causes often involve messy interactions between customer configuration and platform behavior. Here, the important point is less the exact legal allocation of blame and more the architectural implication: even a sophisticated customer can suffer a provider-side administrative failure that defeats normal redundancy.

The incident is also reputationally expensive for Google Cloud because cloud providers sell confidence. They ask customers to move more systems, more data, and more operational dependence into their platforms. Every story like this makes buyers ask a harder question: not just whether a provider can keep machines running, but whether it can guarantee the integrity of the customer relationship, account, and data boundary.

Takeaway

The best reading of this piece is not “do multi-cloud for everything.” It is more precise: know which failures your redundancy actually covers, and do not confuse regional resilience with provider independence.

For high-value data, teams should keep at least one restore path outside the primary provider’s account-level blast radius. They should test that restore path, document who can use it, and make sure access does not depend on the very account or identity system that might be gone. They should also treat billing, support, IAM, and provider-account health as production dependencies worth monitoring and rehearsing.

The UniSuper case is a reminder that managed infrastructure does not remove operational responsibility. It changes where the responsibility sits. Cloud users can outsource a lot of machinery, but they cannot outsource the need to understand what happens when the machinery’s owner makes a mistake.