--- url: "https://xcademia.com/news/google-cloud-introduces-fault-injection-testing-in-preview" title: Google Cloud Introduces Fault Injection Testing in Preview description: Google Cloud launches Fault Injection Testing in preview to help teams test Cloud SQL failover and application traffic resilience. publishedAt: "2026-08-27T09:45:03.146+00:00" updatedAt: "2026-08-27T09:45:24.533118+00:00" type: news category: devops source_name: Google Cloud Blog source_url: "https://cloud.google.com/blog/products/networking/introducing-google-cloud-fault-injection-testing-in-preview" tags: - "#GoogleCloud" - "#FaultInjectionTesting" - "#CloudReliability" - "#ResilienceEngineering" - "#ChaosEngineering" - "#CloudInfrastructure" - "#DevOps" - "#DisasterRecovery" --- # Google Cloud Introduces Fault Injection Testing in Preview > Google Cloud has introduced Fault Injection Testing in preview, helping teams automate controlled failure experiments for Cloud SQL and Layer 7 load balancers to validate application resilience before outages occur. Source: **Google Cloud Blog** · 27 August 2026 Modern cloud applications rely on distributed infrastructure, making it increasingly difficult for developers and architects to predict how critical services will behave when failures occur. A database can fail. Network paths can degrade. A zone can become unavailable. For mission-critical applications, the ability to understand what happens during these disruptions is an important part of reliability planning. Google Cloud is addressing this challenge with **Fault Injection Testing (FIT)**, now available in **public preview**. The service is designed to help developers and architects automate controlled failure testing by deliberately introducing faults into cloud environments. Teams can then observe how applications and their safety mechanisms respond before a real outage affects customers. Google Cloud says FIT gives teams a way to test their safety mechanisms under controlled failure conditions before a real outage affects customers. The preview currently supports two primary failure scenarios: **Cloud SQL failover** and **application traffic degradation **through a Layer 7 load balancer. ## Why Native Resilience Testing Matters Testing how an application behaves during failure is a fundamental part of resilience engineering. However, cloud environments can make certain failure scenarios more difficult to reproduce because organizations generally have less direct access to the underlying infrastructure than they would in self-hosted data centers. Without a way to deliberately test failure conditions, teams may have limited evidence that their failover and recovery mechanisms will behave as expected. Google Cloud identifies several risks associated with this gap. **Damaged Trust and Reputation** Repeated service failures or poor performance can affect customer satisfaction and potentially damage an organization's reputation. **Compliance and Regulatory Risks** Some industries require organizations to demonstrate disaster recovery capabilities. Google Cloud notes that an inability to prove these capabilities can contribute to compliance issues, audits and potential penalties. **Migration Delays** Large-scale cloud migrations can also be affected when teams cannot adequately validate whether critical applications will remain stable during scenarios such as a zone failure. Fault Injection Testing is intended to give teams a controlled way to test these scenarios before they occur in production. ## How Google Cloud Fault Injection Testing Works FIT uses **experiment templates** to define resilience tests. These templates serve as blueprints for an experiment. They specify the fault that should be introduced and the resources that should be targeted. The process can be broadly understood as: **Define Experiment → Dry Run → Review Impact → Start Injection → Observe → Stop Revert** This approach gives teams an opportunity to understand the potential scope of an experiment before introducing the actual fault. **Step 1: Create an Experiment Template** The first step is to define the failure scenario and the resources that will be affected. The template determines what type of fault will be introduced and how long the experiment should run. **Step 2: Perform an Automated Dry Run** Before the fault is injected, FIT performs an automated **dry run**. This is a read-only simulation that checks permissions and provides an up-to-date list of resources that would be affected. This gives teams an opportunity to review the potential scope before starting the actual experiment. **Step 3: Manually Start the Experiment** After reviewing the dry-run results, the experiment can be manually started. The selected fault is then introduced for the duration defined in the experiment template. **Step 4: Monitor Application Behavior** While the experiment is running, teams can observe whether their application behaves according to their resilience expectations. The purpose is not simply to create a failure, but to provide a controlled environment in which teams can verify their existing safety mechanisms. **Step 5: Stop and Revert if Necessary** If an experiment does not behave as expected, FIT provides **stop and revert** capabilities. This allows teams to halt the experiment and begin restoring resources to their normal state. Once the defined experiment duration expires, the injected faults are also reverted. ## ![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1787823399502-info-1--105-.webp) ## Two Failure Scenarios Available in Preview The public preview currently supports two primary types of failure experiments. **1. Cloud SQL Failover** The first scenario involves **Cloud SQL**. FIT can trigger a failover of a high-availability Cloud SQL instance from its primary zone to a standby zone. This provides a controlled way to test how an application responds when the primary database location becomes unavailable. For teams operating applications that depend on highly available databases, such an experiment can help validate whether their application handles the transition as expected. **2. Application Traffic Degradation** The second scenario focuses on application traffic. FIT can selectively introduce **latency and HTTP error codes through a Layer 7 load balancer**. This allows teams to examine how applications respond when traffic experiences degraded conditions rather than an outright infrastructure failure. The two scenarios provide different types of resilience tests: Experiment Failure Scenario Purpose Cloud SQL failover Primary zone to standby zone Test database failover behavior Application traffic degradation Added latency and HTTP errors Test application behavior under degraded traffic ![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1787823706467-info-2--86-.webp) ## The Dry Run Is an Important Part of the Workflow One of the notable elements of FIT is that the service performs a dry run before the fault is introduced. The dry run is **read-only** and checks the permissions required for the experiment. It also provides an updated list of resources that would be affected. This creates a review point between defining an experiment and actually introducing a fault. For resilience teams, that separation can help make controlled failure testing more deliberate. Instead of immediately modifying the environment, teams can first review the expected scope and then manually authorize the experiment. ## Fault Injection Testing Is Designed for Controlled Experiments The objective of FIT is not to create uncontrolled outages. Instead, Google Cloud describes the service as a way to deliberately introduce specific faults so organizations can evaluate application behavior during disruptions. This distinction is important. A resilience test needs to provide enough disruption to exercise failover or recovery mechanisms while maintaining control over the experiment. FIT's experiment templates, dry-run process, defined duration and stop-and-revert functionality are designed around that controlled approach. During an experiment, teams can compare actual application behavior against their expectations. For example, a team testing database failover could observe whether its application continues operating when the Cloud SQL instance transitions from the primary zone to the standby zone. Similarly, traffic degradation testing can help teams observe how their application responds to latency or HTTP errors introduced through the Layer 7 load balancer. ## Google Cloud Recommends Using FIT in Non-Production During Preview Google Cloud recommends using Fault Injection Testing in a **non-production environment during the preview period**. The company describes the preview as an opportunity for organizations to gain early access, understand how FIT complements existing testing practices and provide feedback that can help improve the service. This recommendation is particularly relevant because fault injection deliberately introduces disruptions into the environment being tested. Organizations considering the preview should therefore approach experiments as controlled testing activities and follow their own internal change-management and resilience-testing procedures. ## Enterprise Use Cases Google Cloud says organizations including **KeyBank** and **Servier** are already using Fault Injection Testing to validate their deployments. According to Google Cloud, these organizations are using native fault injection to approximate demanding failure scenarios, including zonal outages, to help assess whether services remain stable. The announcement does not provide detailed performance results, test configurations or specific resilience metrics from either organization. Additional details were not disclosed in the announcement. ## How to Get Started With Fault Injection Testing Fault Injection Testing is available through the: - Google Cloud console - `gcloud` CLI - REST APIs However, access to the preview requires several steps. **1. Request Preview Access** Organizations need to contact their **Google Cloud Account Team** to have their project added to the preview. **2. Enable the API** In the Google Cloud console, search for **Fault Testing API** and enable it. **3. Assign the Required Role** Google Cloud states that teams configuring and running experiments should have the: `roles/faulttesting.operator` role. **4. Run a Dry Run** Google Cloud recommends creating an experiment for a supported Cloud SQL or load balancer resource in a **non-production environment** and running a dry run first. The dry run allows teams to review the potential impact before introducing the fault. ## What Fault Injection Testing Could Mean for Cloud Reliability Google Cloud's introduction reflects a broader industry shift toward making resilience testing more repeatable and integrated with cloud infrastructure. Traditional disaster recovery plans can describe how systems are expected to behave during an outage, but controlled testing provides another way to evaluate those assumptions. For enterprises, this could mean moving from documenting recovery procedures toward regularly testing specific failure scenarios where appropriate. FIT's current preview capabilities focus on Cloud SQL failover and Layer 7 traffic degradation, so organizations will need to determine whether those scenarios match their particular resilience requirements. The development also reflects growing demand for reliability tooling that can work within increasingly complex distributed cloud architectures. ### ![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1787823421148-info-3--80-.webp) ### ## A Controlled Approach to Cloud Resilience The introduction of FIT also highlights an important principle in distributed systems: resilience cannot always be evaluated by looking only at normal operating conditions. Applications may perform correctly when infrastructure is healthy but behave differently when a dependency fails, traffic is delayed or a database changes zones. Controlled failure experiments provide a way to examine those conditions before they become real incidents. For cloud architects and reliability teams, this can make resilience testing a more repeatable part of the development and operational lifecycle. The practical value will depend on how teams design their experiments, interpret the results and incorporate findings into their existing reliability processes. ## What Google Cloud Fault Injection Testing Does Not Yet Cover Because FIT is currently in public preview, its announced functionality is limited. Google Cloud has specifically described: - Cloud SQL high-availability failover - Layer 7 load balancer traffic degradation - Experiment templates - Automated dry runs - Manual experiment execution - Defined experiment duration - Stop and revert capabilities - Google Cloud console access - `gcloud` CLI access - REST API access The announcement does not provide a comprehensive list of all possible infrastructure failures that FIT can simulate. It also does not specify a general-purpose mechanism for injecting arbitrary faults across every Google Cloud service. **The company did not provide specific information about this area.** ## The Bigger Question: Are Cloud Systems Being Tested for Failure Enough? Cloud reliability is often discussed in terms of availability, redundancy and disaster recovery. But those mechanisms need to be tested to determine whether applications actually behave as expected when disruptions occur. Fault Injection Testing introduces a more controlled way to perform those experiments within Google Cloud. The current preview is intentionally focused on a limited set of scenarios, but the underlying approach is broader: define a failure, understand its potential scope, introduce it under controlled conditions, observe the system and restore normal operation. For organizations, the key consideration is not simply whether a fault can be injected. It is whether the resulting experiment provides useful evidence about the application's ability to withstand and recover from disruption. ## Conclusion Google Cloud has introduced **Fault Injection Testing (FIT) in public preview**, giving developers and architects a native way to automate controlled failure experiments. The service currently supports two primary scenarios: **Cloud SQL high-availability failover** and **application traffic degradation through a Layer 7 load balancer**. Its workflow includes experiment templates, an automated dry run, manual fault injection, defined experiment durations and stop-and-revert capabilities. Google Cloud recommends using FIT in non-production environments during the preview period. The introduction reflects a broader shift toward treating resilience as something that should be tested rather than simply documented. For enterprises operating distributed cloud applications, controlled failure experiments can provide additional evidence about how applications behave when critical dependencies or network conditions change. At this stage, FIT remains a public preview with a defined set of failure scenarios. Its current capabilities should therefore be evaluated alongside an organization's existing resilience, disaster recovery and testing practices. ## Original source https://cloud.google.com/blog/products/networking/introducing-google-cloud-fault-injection-testing-in-preview ## Tags `#GoogleCloud` · `#FaultInjectionTesting` · `#CloudReliability` · `#ResilienceEngineering` · `#ChaosEngineering` · `#CloudInfrastructure` · `#DevOps` · `#DisasterRecovery` --- ## About this content This Markdown news article is the citation-grade twin of [Google Cloud Introduces Fault Injection Testing in Preview](https://xcademia.com/news/google-cloud-introduces-fault-injection-testing-in-preview). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite. When citing or quoting, please attribute *Xcademia* and link back to the source URL above. - Source: https://xcademia.com/news/google-cloud-introduces-fault-injection-testing-in-preview - Publisher: Xcademia — https://xcademia.com - Catalogue index: https://xcademia.com/llms-full.txt