Google Cloud Introduces Fault Injection Testing
On August 27, 2026, Google announced the preview of Fault Injection Testing (FIT), a native service for deliberately disrupting Google Cloud resources and checking how applications behave. The initial release is narrow: it can trigger a high-availability Cloud SQL failover or degrade traffic through a Layer 7 load balancer.
That narrow scope is still useful. Database failover and network degradation are two tests that teams often postpone because ad hoc scripts are risky, difficult to review, and hard to run consistently. FIT turns them into reusable experiment templates with an explicit target, fault, and duration.
The two faults available in preview
The public preview supports two scenarios:
- Cloud SQL failover: move a high-availability instance from its primary zone to its standby zone;
- application traffic degradation: selectively introduce latency and HTTP error codes through a Layer 7 load balancer.
The first scenario tests more than whether Cloud SQL can fail over. It exposes assumptions in connection pools, DNS handling, transaction retries, startup probes, and application recovery. The second helps validate timeout budgets, retry policies, circuit breakers, fallback behavior, and user-visible error handling.
FIT is therefore not a general-purpose chaos platform yet. The announcement does not include arbitrary VM termination, packet loss, CPU pressure, storage faults, or multi-step experiments. Teams should evaluate it for the two supported paths rather than extrapolate a broader feature set from the product name.
Dry runs reduce targeting mistakes
Before injecting a fault, FIT performs an automated read-only dry run. It checks permissions and returns an up-to-date list of resources that the experiment will affect. Injection starts manually only after an operator reviews that scope.
This workflow addresses a common fault-testing hazard: a stale selector or unexpectedly broad target. A dry run does not prove that an experiment is safe, but it creates a review point before the disruptive action. Teams should record the returned scope with the change or test evidence and stop if it differs from the expected inventory.
The service also limits the duration of a fault through the experiment template. When that timer expires, FIT reverts the fault. If application behavior becomes unsafe earlier, an operator can use stop and revert to halt the experiment and begin restoring normal conditions.
These controls are guardrails, not a rollback strategy for application data. A forced database failover or a burst of HTTP failures can still expose non-idempotent retries, incomplete transactions, queue growth, or downstream side effects. Recovery criteria and observation dashboards need to be prepared before injection begins.
A practical first experiment
Google recommends using FIT in a non-production environment during preview. A sensible first test should be small enough to diagnose:
- Choose one non-production service with known dependencies and an observable success path.
- Define steady-state signals such as successful requests, latency, error rate, queue depth, and database connectivity.
- Create a template for either its high-availability Cloud SQL instance or Layer 7 load balancer.
- Run the dry run and have another engineer verify every listed target.
- Start with a short duration and watch both application and infrastructure telemetry.
- Exercise stop and revert deliberately, even if the system appears healthy.
- Document recovery time, failed assumptions, and changes required before repeating the test.
For a Cloud SQL experiment, inspect whether existing connections recover and whether new connections succeed without manual intervention. For load-balancer degradation, compare observed latency and errors with client timeout and retry behavior. Retries that hide a fault from users can still multiply backend load, so request volume matters alongside the final success rate.
Access and preview limits
FIT is available through the Google Cloud console, the gcloud CLI, and REST APIs. During preview, access is not an ordinary self-service enablement flow. Google instructs customers to ask their Google Cloud account team to add a project to the preview, then enable the Fault Testing API and grant operators the roles/faulttesting.operator role.
The announcement does not provide a regional availability list or FIT-specific pricing. It is therefore unsafe to assume that the preview is globally available or free. Those details should be confirmed with the account team before planning adoption.
Preview status is the larger operational constraint. Google explicitly recommends non-production use during the preview. Production resilience work can still benefit from the templates and evidence developed in a test environment, but FIT should not become a production control until its support terms and behavior meet the organization’s risk requirements.
Where FIT helps most
The strongest use case is repeatability. FIT can turn a manually coordinated failover exercise into a reviewed template that teams run after changes to connection handling, load-balancer policy, retry logic, or disaster-recovery procedures.
It can also make resilience checks part of migration acceptance. Instead of treating high availability as a configuration checkbox, a team can demonstrate how the complete application behaves when a standby becomes primary or when Layer 7 latency and HTTP errors are introduced.
The preview is not broad enough to replace an existing chaos-engineering toolkit. It does, however, provide a safer native path for two high-value Google Cloud failure modes. The dry run, bounded duration, and stop-and-revert control make those tests easier to review and repeat, while leaving application-level recovery and data safety firmly with the engineering team.