Cloud hosting is often sold as the answer to reliability. And, in many ways, it is.
Large providers invest billions in redundant networks, multiple data centres, automated monitoring and teams of engineers working around the clock. For a growing business, moving systems to the cloud can be far more resilient than relying on a single server in a back office.
But the cloud is not magic. It is still made of physical buildings, hardware, cables, procedures and people.
A recent Google Cloud outage made that point very clearly.
On 1 September 2026, a routine hardware maintenance procedure in Google’s us-central1-b zone caused a severe network outage. The incident lasted roughly four hours, from 07:41 to 11:52 Pacific Time. At its worst, traffic drop rates for affected resources reached 100%, leaving virtual machines unreachable.
The preliminary cause was a procedural error. An engineer sequentially unplugged 100% of the fibre-optic paths across the affected routing devices within 13 minutes. In doing so, the maintenance work defeated the very redundancy Google had designed to protect the environment.
Fifteen Google Cloud services were affected, including Compute Engine, Google Kubernetes Engine, BigQuery, Cloud SQL, AlloyDB, Cloud Spanner, Cloud Run, App Engine, Cloud Bigtable, Cloud Dataflow, Cloud Filestore, Apigee, VPC, Hybrid Connectivity and Looker.
You can read Google’s incident report for the technical detail. But the business lesson is simpler:
Redundancy only helps when it covers the failure that actually happens.
What happened during the Google Cloud outage?
Google’s infrastructure was designed to withstand individual device and fibre-path failures. Routing devices were separated, network paths were duplicated and traffic could be moved to healthy capacity.
That is a sensible design.
The problem was that the maintenance procedure did not fail one device or one path. It removed every fibre path across the affected devices, one after another, in a short period.
The engineer was carrying out a planned capacity upgrade. The work involved replacing optical transceivers connected to data-centre routers. However, the instructions did not properly sequence the task one router at a time, with the expected checks between each stage.
As a result, a process intended to improve the network temporarily disconnected all of its available paths.
The effect was significant:
- Virtual machines in the affected area became unreachable.
- Some systems could not connect to resources outside the zone.
- Customers experienced packet loss, errors, timeouts and service failures.
- Workloads using dependent services could also be affected.
- Traffic had to be rerouted to healthy capacity elsewhere.
- Engineers and hardware technicians had to identify and physically reseat the disconnected fibres.
Google’s systems detected the issue quickly. Its teams began moving traffic away from the affected infrastructure while technicians restored the physical connections.
That response limited the damage. But it did not make the outage invisible to customers whose workloads were tied to the affected area.
Why did Google’s redundancy not prevent the outage?
It is tempting to look at this incident and conclude that cloud redundancy does not work.
That would be the wrong conclusion.
Google’s redundancy appears to have worked as designed against many individual failures. The difficulty was that the maintenance procedure created a larger, correlated failure across all the redundant paths.
This distinction matters.
Imagine a business with four network connections. If one connection fails, the other three can carry the traffic. But if a single action disconnects all four connections, having four connections has not protected the business from that particular event.
This is known as a single point of failure in a wider sense. The cable was not necessarily the only point of failure. The maintenance process, sequencing and verification controls were also part of the system.
The Register described the event as an engineer unplugging “every fibre they could see”. Google’s own report explained that the work disconnected 100% of fibre paths across the affected devices within 13 minutes. The details are uncomfortable, but they are useful.
A resilient environment must account for:
- Hardware failure
- Network failure
- Software bugs
- Configuration mistakes
- Human error
- Supplier outages
- Failed updates
- Cyberattacks
- Problems that affect multiple supposedly independent systems
The last point is particularly important. Two servers are not truly independent if they share the same power source, network switch, building, administrator account or maintenance procedure.
The risk of putting everything in one zone
For many small and growing businesses, cloud architecture starts simply.
A website, database or application is deployed in one location. It works well, costs little and is easy to manage. Over time, more business processes depend on it.
The website handles enquiries. The database stores customer records. The application supports staff. A payment or booking system connects to the same environment.
The business may believe it has “moved to the cloud”, but it may still be relying on one zone, one provider or one set of connected services.
That is not necessarily wrong. Every organisation has to balance resilience against cost and complexity. But it is important to understand the trade-off.
If your critical workload sits entirely in one availability zone, a zonal network failure can affect the whole service. If every system depends on one cloud provider, a provider-wide incident or account problem may have a larger impact. If your backups live in the same environment as your production systems, they may not be available when you need them.
The cloud removes some infrastructure risks. It does not remove the need to understand infrastructure risk.
What can UK businesses learn from this incident?
1. Spread important workloads across zones or regions
For critical systems, consider distributing workloads across multiple availability zones. For especially important services, a second region may be appropriate.
This does not mean every SME needs an elaborate global architecture. A Cardiff professional services firm may not need servers on three continents. But it may need its public website, customer portal or line-of-business application to survive the loss of one zone.
Ask:
- What happens if this zone becomes unavailable?
- Can traffic automatically move elsewhere?
- Is the database replicated?
- Are application components genuinely independent?
- How long would manual recovery take?
2. Do not confuse a big provider with complete protection
Google, Microsoft and Amazon all operate highly capable cloud platforms. Using one of them can be a sensible choice.
However, “hosted by a hyperscaler” does not automatically mean “resilient for my business”. The architecture, configuration and recovery plan still matter.
For some organisations, using more than one provider may be justified. For others, the better answer may be a carefully designed managed hosting environment with independent backups, tested recovery and clear support responsibilities.
The right question is not simply, “Which cloud is best?”
It is:
Which design gives our business an acceptable recovery time and recovery point if something goes wrong?
3. Treat backups as a recovery system, not a tick box
A backup that has never been restored is an assumption, not a tested plan.
Growing businesses should understand:
- How often backups run
- Where they are stored
- Whether they are isolated from production systems
- How long they are retained
- How quickly they can be restored
- Who is responsible for recovery
- Whether the restored data is complete and usable
Daily backups may be enough for some websites. Customer-facing applications or transactional systems may need hourly backups or more frequent replication.
Picnic IT’s managed hosting services include daily and hourly backup options, alongside monitoring, security and performance management.
4. Have a disaster recovery plan before an incident
A disaster recovery plan should not begin with, “Call the IT company.”
It should define what happens next.
For example:
- How is an outage detected?
- Who makes the decision to fail over?
- Which services are restored first?
- How do staff communicate if email is unavailable?
- How are customers updated?
- What recovery time is acceptable?
- When do you return to normal operations?
- How is the incident reviewed afterwards?
For a small UK business, this could be a concise and practical document rather than a huge technical manual. The important thing is that people know what to do, and that the plan has been tested.
5. Look beyond SLA credits
Cloud service-level agreements can provide reassurance, but compensation is usually limited.
An SLA credit may cover a small portion of the hosting bill. It will not necessarily cover:
- Lost sales
- Missed appointments
- Staff downtime
- Emergency contractor costs
- Reputational damage
- Customer support time
- Delayed projects
- Regulatory or contractual consequences
SLA credits are useful, but they are not a disaster recovery strategy.
The best protection is reducing the likelihood and impact of failure in the first place.
Where managed hosting can help
Resilience can become complicated quickly. Zonal design, backups, monitoring, security, failover and performance tuning are not always areas a growing business wants to manage internally.
That is where a managed hosting partner can help.
At Picnic IT, we design and manage hosting environments for businesses that need more than a basic server plan. Depending on the requirement, this can include:
- UK-based hosting infrastructure
- 99.9% uptime targets
- Proactive monitoring
- Daily or hourly backups
- CDN support for faster content delivery
- Server hardening and patching
- Scalable hosting options
- Ongoing technical support
The goal is not to promise that nothing will ever go wrong. No responsible technology provider can promise that.
The goal is to make failures less likely, spot them sooner and recover more effectively when they happen.
Key Insights for growing businesses
- Cloud hosting is powerful, but it is not automatically immune to outages.
- Redundancy must cover correlated failures, including human and procedural errors.
- Do not place every critical workload in one zone without understanding the risk.
- Consider multi-zone, multi-region or multi-provider options where the business case supports them.
- Keep backups separate, frequent and tested.
- Create a disaster recovery plan before the incident happens.
- Remember that SLA credits are not the same as business continuity.
- Use managed hosting and outsourced IT services when your team needs expert support without managing every infrastructure detail alone.
The wider lesson: resilience is a business decision
The Google Cloud outage was triggered by a physical maintenance error. That does not make it irrelevant to smaller organisations.
A misplaced configuration, failed update, damaged cable or compromised administrator account can create the same kind of problem at any scale. The technology changes, but the principle remains: a system is only as resilient as its weakest shared dependency.
For businesses reviewing their cloud security for SMEs, the conversation should include more than firewalls and passwords. It should also cover availability, recovery, hosting architecture and operational resilience.
If your website, applications or data are essential to your business, now is a good time to ask what would happen if your main hosting environment disappeared for four hours.
Would you keep trading? Could your team work? Could customers still reach you? How much data would you lose?
If the answers are unclear, that is not a reason to panic. It is a reason to review the design before an outage forces the question.
Talk to Picnic IT about managed hosting and resilient IT infrastructure solutions. We can help you understand where your current setup has single points of failure and build a practical path towards better protection.