What the INDIGO Cable Faults Tell Australian Businesses About Website Resilience

The reported faults affecting the INDIGO West and INDIGO Central submarine cable systems off Western Australia in early August 2026 are a useful reminder of something most businesses rarely think about: the internet is not floating around in a cloud. It eventually comes back to physical infrastructure.

I find that part interesting because the word "cloud" has trained people to think of digital services as abstract. Websites, email, accounting systems, customer portals, booking systems and analytics dashboards all feel as though they live somewhere vague and infinitely available. In practice, they live in data centres, depend on power, use routing decisions made by networks, rely on DNS, and cross oceans through fibre-optic cables sitting on the seabed.

That does not mean Australian businesses should panic every time a submarine cable has a fault. Cable faults happen. Networks route around them. Good carriers design for failure. The point is more practical: if your business depends on being reachable online, you should have at least a rough understanding of where your public website and its dependencies actually live.

What happened off Western Australia?

The reported incident involved faults on two related submarine cable systems off Perth around 8 and 9 August 2026.

INDIGO West is the Perth-to-Singapore part of the INDIGO system, providing a direct route from Western Australia into Asia. INDIGO Central provides a submarine route between Perth and Sydney, running around southern Australia rather than relying only on terrestrial east-west paths.

The faults have been reported as shunt faults. In simple terms, a shunt fault usually means an electrical power problem in the cable system rather than a clean fibre break where the glass fibre itself is simply severed. Submarine cables are not just passive strands of fibre. Long systems use powered repeaters along the route to keep the optical signal usable across thousands of kilometres. A fault in the power path can interrupt or degrade the system even if the fibre is not neatly cut in two.

There has also been public speculation about deliberate interference because two faults occurred close together in time and location, the area was within the Perth Submarine Cable Protection Zone, and a vessel was reportedly operating nearby.

That speculation needs to stay in its lane.

At the time of writing, there is no confirmed public evidence that the INDIGO faults were a deliberate attack or sabotage. The Australian Federal Police is assessing the matter. SUBCO has also been reported as saying that the physical cause cannot be confirmed until the affected cable is recovered and examined.

That distinction matters. A suspicious pattern is not the same thing as proof. Anyone who runs infrastructure for long enough learns to be careful about first explanations. Sometimes the boring explanation is right. Sometimes it is not. You do not know until the evidence is available.

From a resilience point of view, however, the cause is not the first business question. Whether a cable fails because of an anchor, equipment failure, operational mistake, natural event or hostile action, the immediate engineering question is similar: can the network absorb the failure?

In this case, traffic was rerouted through other connectivity, which is why Australia did not suddenly lose internet access.

That is how the internet is meant to behave.

Australia depends heavily on submarine cables

Australia's international internet connectivity is overwhelmingly dependent on submarine fibre-optic cables. Satellite connectivity has useful roles, especially in remote areas and specific backup scenarios, but it is not a substitute for the capacity and latency of modern subsea fibre.

The ANU National Security College report, Connected & Protected: Building Australia's Submarine Cable Resilience, states that around 16 privately operated submarine cables support approximately 99% of Australia's international communications and data connectivity.

That is a remarkable concentration of practical dependence.

This is not only a telecommunications issue. It touches banking, health, cloud services, emergency communications, government, logistics, media, retail, mining, professional services and ordinary small business operations. Many Australian businesses now run Microsoft 365, Google Workspace, Xero, CRMs, booking platforms, payment systems, authentication services and support tools that may depend on international paths even when the customer and the business are both in Australia.

Defence Minister Richard Marles made a similar strategic point at the 2026 Shangri-La Dialogue, describing the seabed as a major field of contest and noting Australia's exposure through a small number of physical cable assets. His speech was about national security, not small business web hosting, but the underlying lesson is familiar to anyone who designs systems: hidden infrastructure still matters.

The ANU report also points to resilience issues that are bigger than any one cable fault. Australia does not have a single comprehensive submarine cable strategy. Responsibility is spread across multiple agencies. Repair vessel availability can depend on private and foreign capability. Surveillance and monitoring are difficult. Redundancy is uneven. Government and private-sector coordination matters because most of the infrastructure is privately owned, while the national consequences of failure are public.

That is not a criticism of any one operator. Submarine cables are expensive, specialised infrastructure. The issue is that national resilience is a system problem. Ownership, regulation, repair capability, maritime monitoring, landing stations, domestic backhaul, route diversity and incident coordination all interact.

Protection zones reduce risk, but they do not make cables invulnerable

Australia does have submarine cable protection zones. The ACMA's Perth Protection Zone extends 60 nautical miles, or 112 kilometres, off City Beach, to a water depth of 2000 metres, and one nautical mile each side of the cable.

Within that zone, certain activities are prohibited or restricted. ACMA lists restrictions around anchoring, trawling, dredging, demersal fishing methods, grapnels and other activities that can damage cables or disturb the seabed. Damage to a submarine cable, negligent conduct causing damage, and prohibited or restricted activities can be criminal offences.

That is sensible risk reduction. It is not a force field.

A protection zone improves the legal and operational environment around a cable. It helps mariners know where care is required. It creates consequences for conduct that damages critical infrastructure. It supports enforcement. But it cannot physically stop every anchor, dragged object, mechanical failure, mapping error, deliberate act or unexpected event.

This is the same pattern we see in smaller systems. A firewall reduces risk, but it does not make a bad application safe. MFA reduces account compromise risk, but it does not remove the need to manage access properly. A backup is helpful only if it can actually be restored. A cable protection zone is one layer in a resilience model, not the entire model.

Domestic routing matters too

It is easy to focus on international submarine cables and forget the domestic internet architecture that determines how traffic moves inside Australia.

If an Australian customer visits an Australian business website, it is not automatically true that the traffic stays inside Australia. That depends on where the site is hosted, where DNS resolves, which CDN is used, how the hosting network peers, whether the customer's ISP has a sensible domestic route, and whether third-party assets or APIs are needed before the page works.

This is where domestic peering and Internet Exchange Points matter.

APNIC has a useful article on recognising IXPs as critical infrastructure. In plain English, an Internet Exchange Point is a place where networks can exchange traffic directly instead of sending it through an upstream provider or a longer path. Good peering can reduce latency, reduce cost and help keep local traffic local.

During a serious international connectivity disruption, the difference between local and international paths can become very obvious. If two Australian networks can still exchange traffic domestically, services hosted and resolved within that domestic ecosystem may remain reachable even while some international routes are degraded.

Again, there are qualifications. Domestic peering is not magic. It depends on the networks involved, their routing policies, capacity, DNS, hosting, data centre connectivity and failover design. But it is part of the resilience conversation, and it is often invisible to business owners buying a website or hosting plan.

Where does your Australian business website actually live?

This is the smaller version of the national problem.

A business can have a .com.au domain, Australian customers, Australian phone numbers, Australian staff and Australian content, while the public website depends on infrastructure in Singapore, the United States, Europe or several places at once.

That is not automatically bad. There are good overseas providers, and many global platforms are professionally run. The problem is not "overseas equals unsafe". The problem is unexamined dependency.

An Australian website may depend on:

• overseas web hosting
• an overseas CDN configuration
• overseas authoritative DNS
• fonts loaded from a third-party provider
• JavaScript libraries loaded from public CDNs
• analytics scripts
• advertising pixels
• CRM forms
• third-party booking widgets
• payment scripts
• authentication systems
• APIs hosted in another region
• SaaS platforms needed before pages render properly

It is perfectly possible for an Australian customer requesting information from an Australian company to depend unnecessarily on an international network path.

Most of the time, nobody notices. The page loads. The form works. The analytics script fires. The font comes from wherever the browser is told to get it. But when networks are congested, paths change, DNS has trouble, a CDN makes an odd routing decision, or an international link is degraded, those hidden dependencies can become visible.

This is one reason I like reviewing real websites rather than just talking about hosting brands. The label on the hosting account is only one part of the answer. The actual page load tells you much more.

Australian hosting helps, but only if the dependency chain is engineered properly

I do build and migrate business websites so that the core public-facing web presence is hosted using Australian infrastructure where that makes sense.

That can include Australian-located web hosting, a second geographically separate Australian server where required, resilient authoritative DNS, local website assets, self-hosted fonts and JavaScript libraries where sensible, fewer third-party runtime dependencies, static-first architecture, local monitoring, server hardening, dependency audits and resilience reviews.

But I would not sell this as "host in Australia and your website will work if the international cables go down". That is too simplistic.

For an Australian customer to continue reaching a site during a severe international connectivity disruption, a chain of things needs to hold:

• the web server should be in Australia
• the hosting network should have appropriate domestic connectivity
• Australian ISPs should be able to route to it domestically
• authoritative DNS should remain available to Australian resolvers
• required site assets should be hosted locally
• the site should not need overseas APIs to render ordinary public pages
• essential authentication should not be offshore if it is needed for public access
• critical database or application services should not sit only overseas
• CDN configuration should not accidentally send Australian requests offshore

DNS deserves particular caution. It is easy to say "Australian DNS" and make it sound simple, but authoritative DNS is usually distributed by design. The relevant question is not only the provider's billing address. It is where the authoritative nameservers actually sit, how they are anycasted, what networks they use, whether Australian resolvers can reach them during disruption, and whether there is provider diversity.

For many small business websites, the correct target is not a perfectly Australian-only system. It is a measured reduction in unnecessary external dependency, with clear understanding of what remains.

That is an engineering service, not a hosting slogan.

A continuity website can be a practical middle ground

Many businesses should not move all systems away from Microsoft, AWS, Google, Xero, Shopify, HubSpot or other SaaS platforms. Those tools may be central to operations, and replacing them just to make a theoretical resilience point would be expensive and unnecessary.

A more practical option is a lightweight Australian-hosted continuity website.

Think of it as the public information site the business can rely on when normal systems are disrupted. It does not replace the main operational stack. It does not need every feature. It does not need customer accounts, a CRM integration, marketing automation or a complex CMS.

In a serious overseas connectivity outage, a continuity site could potentially still provide Australian customers with:

• current company status
• phone numbers
• physical locations
• opening hours or operating information
• emergency announcements
• alternative contact arrangements
• service availability information
• links to local documents or instructions

For a clinic, that might mean telling patients which phone number to use and whether appointments are continuing. For a professional services firm, it might mean publishing urgent contact details and settlement or filing instructions. For a trades business, it might mean service-area updates and emergency numbers. For a school, association or community organisation, it might mean keeping basic notices available even when a larger platform is struggling.

This does not need to be overbuilt. In fact, overbuilding it defeats the point.

Why static architecture fits this use case

A business-continuity website is usually informational. That makes it a good candidate for static architecture.

A static site is generated ahead of time as HTML, CSS and JavaScript. It does not require a live database for ordinary page delivery. It does not require a public CMS admin area to assemble every page request. It can be served from simple web infrastructure, replicated more easily, monitored cleanly and kept deliberately small.

That has several practical advantages:

• fewer moving parts
• no database required for public page delivery
• easy replication to another Australian location
• smaller public attack surface
• predictable performance
• less dependence on unrelated SaaS availability

This is not an argument that every business website must be static. If the main site needs eCommerce, bookings, memberships, private portals or complex workflows, those dynamic systems may be justified. They just need proper design, maintenance and recovery planning.

But for a public continuity site, static is often exactly the right tool. The objective is to publish essential information reliably, not to recreate the whole business system.

For related background, I have written separately about when a WordPress brochure site should become a static website and the security lessons from the Australian AI gym website incident. Different issue, same underlying habit: remove public complexity that the business does not really need.

What I would check in a resilience audit

For an Australian SME, I would start with a dependency map rather than a product recommendation.

The useful questions are straightforward:

• Where is the website actually hosted?
• Which network announces the hosting IP address?
• Does the hosting provider have good Australian domestic connectivity?
• Where are the authoritative DNS nameservers?
• Which third-party scripts are required for the page to render?
• Are fonts, CSS and JavaScript loaded locally or from overseas services?
• Does the contact form depend on an overseas form processor?
• Does the site need an overseas API before public content appears?
• Is the CDN routing Australian visitors to Australian infrastructure?
• Can the site still publish basic information if the CMS, CRM or SaaS stack is unavailable?
• Who can update emergency content if the usual agency or platform is unavailable?
• Is there monitoring from inside Australia?

Some answers will be fine. Some will be acceptable trade-offs. Some will be unnecessary dependencies that can be removed in an afternoon.

For example, self-hosting a font is usually simple. Removing unused analytics and marketing scripts can improve both privacy and performance. Replacing a fragile embedded form with a simpler local form handler may be sensible. Moving a brochure-style WordPress site to a static build may remove an entire runtime dependency. Adding a small continuity site may be cheaper and cleaner than trying to make a complex main site solve every emergency scenario.

The point is not purity. The point is knowing what the business depends on.

The lesson for small businesses

The INDIGO faults are a national infrastructure story, but they also make a useful small-business point.

Resilience is not achieved by assuming someone else has handled it. It comes from understanding the chain, reducing avoidable dependencies and designing for ordinary failure before the unusual failure arrives.

For most Australian SMEs, the sensible action is not to commission an enterprise disaster-recovery programme. It is much simpler:

• know where your website, DNS and key assets live
• reduce unnecessary overseas runtime dependencies
• keep the core public website simple where possible
• use Australian infrastructure where it genuinely improves reachability
• make sure DNS and routing assumptions are checked, not guessed
• maintain a lightweight continuity option if public communication matters

That is the kind of practical resilience work I think many Australian businesses should be doing. Not because every cable fault will become a crisis. Because small, clear engineering decisions made before an incident are much easier than hurried decisions made during one.

Solway Web Consulting can review an existing business website, map its hosting and runtime dependencies, migrate suitable sites to Australian-hosted static infrastructure, harden servers and DNS, and build a lightweight Australian-hosted continuity site where that would be useful.

If you are not sure where your website really lives, start there: book a consultation with Solway Web Consulting.

Sources and Further Reading

• SUBCO: INDIGO West
• SUBCO: INDIGO Central
• ANU National Security College: Connected & Protected: Building Australia's Submarine Cable Resilience
• ACMA: Zone to protect Perth submarine cables
• Richard Marles: Address to the 2026 Shangri-La Dialogue
• APNIC: Recognizing IXPs as critical infrastructure