Google Cloud ships fault injection in preview to prove apps survive a zone failure
Google Cloud launched Fault Injection Testing in preview: experiment templates automate Cloud SQL failover and Layer-7 traffic degradation, with a dry-run and automatic revert. GCP teams without a chaos engineering practice now have a native on-ramp, at a deliberately narrow scope.
August 27, 2026. Two scenarios. A dry-run before every injection. Google Cloud announced Fault Injection Testing (FIT) in preview: a managed service that deliberately triggers failures to verify an application survives them, with an automated dry-run and a revert on a timer. For GCP teams that never stood up chaos engineering, it is the first native path; for those who already have a practice, the scope is deliberately narrow.
Why Google is moving resilience into the product
Google Cloud’s argument fits in one sentence: in the cloud, you no longer have direct access to the infrastructure to trigger a failure “cleanly.” In a self-hosted datacenter, an operator unplugs a cable or cuts a switch; in the cloud, the lower layers are abstracted away. Without a native tool to prove an application survives a failure, the reliability strategy keeps a hole that three risks fill in: trust and reputation damaged after repeated incidents, regulatory penalties for sectors that must demonstrate disaster recovery, and migrations that stall when a team cannot verify a critical application holds up through a zone failure.
FIT answers by automating the painful part: designing, triggering, watching and reverting a deliberate failure. The service is built on experiment templates, blueprints that define the fault to inject and the resources to target. In preview, two scenarios are available.
The two failures FIT can inject
The first scenario is Cloud SQL failover: FIT triggers a high-availability Cloud SQL instance to switch from its primary zone to its standby zone. That is the exercise every production team dreads doing by hand — cutting the primary zone of a database and watching whether the application fails over without loss.
The second is application traffic degradation: FIT selectively adds latency and HTTP error codes through a Layer-7 load balancer. Where failover tests recovery, degradation tests resilience: how the application, its timeouts and its retries behave when part of the traffic becomes slow or fails.
The sequencing is what separates FIT from a one-off failure script. Before any injection, the service runs an automated dry-run: a read-only simulation that checks permissions and returns an up-to-date list of every resource that will be affected. Only after confirming that scope does the injection start, manually. The fault runs for the duration defined in the template, then the faults are reverted when the timer expires. If the experiment goes sideways, a stop and revert capability halts the exercise and restores the nominal state.
A scope that is still narrow
FIT’s positioning is honest about its limits. Google Cloud explicitly recommends using it in non-production during preview, as a chance to learn how the service fits existing practices. Two partners, KeyBank and Servier, already validate deployments with FIT by approximating demanding scenarios such as zonal outages.
The technical scope is narrow too: two fault types, oriented network and database, with no CPU, memory or disk faults inside pods. A complete chaos engineering practice — the kind offered by Chaos Mesh, LitmusChaos or commercial platforms — spans a far wider spectrum and works multi-cloud. FIT is not competing with those tools on that ground; it occupies their first rung, the one most teams never climbed.
Access follows the usual channels: the Google Cloud console, the gcloud CLI and REST APIs. Enablement goes through the Fault Testing API, and running experiments requires the roles/faulttesting.operator role. The recommended onboarding path is signposted: request preview access, enable the API, assign the role, then run a first dry-run against a non-production resource.
To measure the distance travelled, compare the current state to the target state. Today, a Cloud SQL failover is triggered by hand, with no safety net and no automatic revert:
# Manual failover of an HA Cloud SQL instance (what FIT automates, bounds and reverts)
gcloud sql instances failover INSTANCE_NAME --project=PROJECT_IDFIT wraps exactly that command in a template, a dry-run and a timed revert — the difference between a repeatable exercise and an emergency gesture.
FIT against AWS FIS and self-hosted chaos
FIT does not enter an empty field. AWS has offered Fault Injection Service (FIS) for years, spanning a wider spectrum — instance, network and disk faults — and wired into CloudFormation-coded experiments. Google Cloud chooses to start narrow instead: two scenarios, but native and console-driven, with no infra-as-code stack to write first.
The comparison runs on three axes. On fault coverage, FIS and self-hosted tools like Chaos Mesh inject application-level and multi-cloud faults that FIT does not reach yet. On friction, FIT wins: an automated dry-run that lists affected resources before injection, and a timed revert by default, remove the two classic excuses for not testing. On regulatory proof, being able to produce a reproducible experiment report from a managed service carries weight in a continuity audit.
The choice is therefore not binary. A GCP team starting out should adopt FIT for the native part and keep Chaos Mesh for the faults FIT does not cover — pod failures, CPU saturation, inter-service latency. The two tools complement more than they compete.
Running a game day with FIT
A game day is the collective exercise where a team triggers a deliberate failure and watches its own response. FIT becomes its natural scaffolding: the template freezes the scenario, the dry-run makes it safe, and the timer guarantees the artificial incident ends.
The recommended flow is four beats. Before: run the dry-run to confirm scope and notify the teams involved. During: trigger the injection manually, then watch the dashboards, the alerts and the behavior of your retries. If it goes sideways: use stop and revert to restore the nominal state without waiting out the timer. After: record the gaps between expected and observed behavior, and turn each gap into a ticket.
That is where FIT’s value materializes: a game day that today costs a day of preparation shrinks to a template and a bounded execution. The preview still restricts you to non-production, but the mechanics — template, dry-run, revert — are exactly what production will expect. The deeper payoff is cultural: teams that run game days regularly stop treating failures as surprises and start treating them as design input. A managed fault-injection primitive lowers the cost of that habit to the point where skipping it becomes the harder choice — which, for most organizations, is the whole point.
The preview framing is itself the signal to read. Google is validating how FIT fits existing practices before widening it, and the natural next step is more fault types and production support once that feedback loop closes.
Verdict
If you are on GCP with no chaos engineering practice, start with FIT in non-production as soon as preview access opens: the automated dry-run removes the fear of breaking things, and the two scenarios cover the failures you must prove for a continuity audit. The cost of entry is a template and a role, not a redesign.
If you already run multi-cloud chaos or need application-level faults, keep Chaos Mesh or the equivalent, and treat FIT as a complement for the GCP-native part — failover and L7 degradation — your tools do not drive as cleanly. The preview scope is too narrow to replace a chaos platform; it is exactly the right size to start one.