The August 2015 Lightning Strike Outage: When europe-west1 Lost Power

Root cause

The trigger for this one was literally out of the sky. On August 13, 2015, four successive lightning strikes hit the local electrical grid serving Google's europe-west1 facility in St. Ghislain, Belgium. The strikes did not damage the disks directly. They disrupted the utility power feed into the facility, and while data centers are built with battery and generator backup, the repeated strikes in quick succession stressed the power systems enough that a portion of the persistent-disk storage fleet briefly lost power.

That brief loss of power is where the interesting failure lives. A disk that is idle when power drops loses nothing. A disk that is mid-write - holding data in a buffer that has not yet been flushed to durable storage - can lose that in-flight write entirely, because the write never made it to stable storage. Most affected disks recovered as soon as power stabilized, and the vast majority of data was intact. But Google's own post-incident report was refreshingly honest: approximately 0.000001 percent of the disk space in the region suffered permanent data loss. Small, but not zero, and unusually candid for a cloud provider to disclose.

This is a different shape of outage from the global control-plane failures. It was regional, it was physical, and its most serious consequence was not downtime but durability - a handful of bytes that were simply gone, not merely temporarily unreachable.

Business impact

For most europe-west1 customers, the impact was a window of elevated persistent-disk errors and latency that resolved as power came back - annoying but recoverable. For the unlucky few whose data happened to be mid-write on an affected disk at the instant of the power loss, the impact was categorically worse: data that could not be recovered from the disk itself. Customers who kept backups or replicated to another region restored cleanly; customers who treated a single region's persistent disk as their only copy of the data had no recourse for the lost writes.

That split is the entire moral of the incident. Downtime you wait out. Lost data you can only restore from a copy you made earlier, somewhere else. If you want to understand how a regional storage event maps to recoverable credits versus unrecoverable loss, the GCP SLA credit calculator is useful for the downtime portion - but no SLA credit brings the bytes back.

It is worth sitting with how small 0.000001 percent really is, and why it still matters. Across a region holding enormous volumes of customer data, that fraction is a vanishingly thin sliver - the overwhelming majority of europe-west1 data survived untouched. But probability at that scale is not comfort if your bytes were the ones in the sliver. Durability is not an average you experience; it is a coin flip you either win or lose for each specific object. Google's willingness to publish the exact figure, rather than round it to "no data loss," set a useful industry precedent: providers that quantify their durability failures let customers reason honestly about the residual risk they carry, instead of assuming a single region is infallible.

Prevention and lessons

1. Never treat one region as your only copy of the data. The permanent loss hit writes that existed nowhere else at that instant. Replicate critical data to a second region or take regular, tested backups off the primary. Our multi-region GCP architecture guide covers durable cross-region patterns.
2. Understand write durability, not just availability. An SLA promises uptime, not that every in-flight byte survives a power event. Use durable-write settings, flush critical data, and for the most important state prefer services with synchronous cross-zone or cross-region replication.
3. Physical events are regional by nature - plan for a region to vanish. Lightning, fiber cuts, and power failures do not respect your multi-AZ setup within a single region. A tested failover to another region is the only real defense, the same lesson as the June 2019 network congestion event.
4. Separate durability alerts from availability alerts. This incident was mostly an availability blip with a durability tail. Instrument for data-integrity signals, not only uptime, and when you do file for the downtime portion the GCP credit playbook covers Google's 30-day claim window. Monitoring tools like Next Signal can watch provider status and assemble the evidence for a regional claim.