Date: Nov 05, 2026

Subject: Undersea Cable Cuts and East African Connectivity: Building for the Bad Day

Undersea Cable Cuts and East African Connectivity: Building for the Bad Day

$ ping payments.yourbank.co.ke

Request timeout...

Request timeout...

$ traceroute payments.yourbank.co.ke

1 gateway.local 0.8ms

2 isp-nairobi-core 4.2ms

3 * * * (no response — upstream cable fault)

$ status: DEGRADED. M-Pesa callbacks delayed. eTIMS portal unreachable.

$ _

Undersea fibre optic cable cross-section

Every few years, a piece of infrastructure most Kenyan business owners have never thought about — a fibre-optic cable lying on the floor of the Indian Ocean — gets damaged, and suddenly half of Nairobi's offices are complaining that "the internet is slow." If you run a business that depends on the internet to take payments, file tax returns, serve customers, or simply keep the lights on in a cloud dashboard, it is worth understanding why this happens, why it affects you specifically, and what you can actually do about it before the next one happens — because there will be a next one.

Why East Africa Is Exposed

Kenya's internet does not originate in Kenya. The vast majority of the data that leaves this country — your card payment authorisation, your cloud backup, your Zoom call with a client in London — travels through submarine cables that run along the East African coast and connect onward to Europe, the Middle East, and Asia. These cables land at a small number of physical points along the coastline, and from there the traffic is distributed inland through terrestrial fibre to Nairobi and other towns.

This is a sensible and normal way to build global internet infrastructure — no country builds its own private internet — but it does mean that East Africa's connectivity to the rest of the world runs through a relatively small number of physical chokepoints. When one of those cables is damaged, whether by a ship's anchor, an undersea landslide, or equipment failure, the traffic that was flowing through it has to be rerouted through the remaining cables. If several cables are affected around the same time, or if the remaining capacity is already heavily used, the result is congestion: slower speeds, timeouts, and services that are technically "up" but too slow to use.

This has happened before and will happen again. The exact cause, the cables involved, and the duration of any given incident are details you should get from your ISP or from local news reporting at the time — this article is not going to guess at specifics, because the point isn't the last incident, it's the pattern. The pattern is: East Africa's international bandwidth is not infinite, it is not fully redundant in practice, and it is physically concentrated in ways that make regional outages possible.

What "Redundant" Actually Means in Practice

ISPs and cloud providers like to say their networks are "redundant," meaning traffic can be rerouted if one path fails. This is true, but redundancy has limits. If cable A goes down and your ISP reroutes you through cable B, that's redundancy working. But if cable B is also near capacity because half the ISPs in the region just rerouted onto it, you still experience degraded service — you're not offline, but you might as well be if your point-of-sale system times out waiting for an M-Pesa confirmation. Redundancy reduces the chance of total blackout; it does not guarantee normal performance during an incident.

Why This Matters More for Some Businesses Than Others

Not every business is affected equally. A retail shop that only uses the internet to check email occasionally will barely notice a regional slowdown. A fintech processing real-time payments, a SACCO running its core banking system on a cloud platform, or a clinic relying on an internet-based patient records system will feel it immediately and painfully. The businesses most exposed are the ones that have — correctly, for good reasons — moved critical operations onto cloud services or payment rails that assume fast, reliable internet is always available.

The eTIMS and Compliance Angle

Kenyan businesses are increasingly required to interact with KRA systems in real time, particularly around invoicing through eTIMS. If your point-of-sale or invoicing software depends on reaching a KRA endpoint at the moment of sale, a connectivity incident doesn't just slow you down — it can interrupt your ability to issue a compliant invoice at all. It's worth checking, as part of your own business continuity planning, what your invoicing software does when it cannot reach eTIMS: does it queue the invoice and submit later, or does it block the sale entirely? This is a question for your software vendor, not something to assume, and KRA's own guidance on acceptable offline handling is something you should confirm directly with KRA or your tax advisor rather than guess at.

The M-Pesa and Payments Angle

Most Kenyan SMEs run on M-Pesa, and most M-Pesa integrations — whether it's a Lipa na M-Pesa till, a paybill, or an API-based checkout — depend on your systems being able to send and receive confirmations over the internet in a timely way. During a period of regional congestion, callback confirmations can be delayed. A customer pays, your system doesn't get the confirmation promptly, and now you have a till operator unsure whether to hand over goods. This is a solvable problem with the right design, but only if you've thought about it before it happens, not during.

The Cloud Dashboard Angle

If your core business systems — accounting, inventory, HR, customer records — live entirely in cloud software accessed through a browser, a severe connectivity incident can mean your staff simply cannot work, even though your office has power and your laptops are fine. This is a real operational risk that's easy to overlook because most days, connectivity is good enough that you never think about it.

What You Can Actually Do About It

You cannot fix submarine cables, and you should not try to solve this problem by panicking and buying things you don't need. The goal is not "never be affected by an outage" — that's not realistic for a small or mid-sized business. The goal is to make sure a bad connectivity day degrades your business gracefully instead of breaking it completely.

Diversify Your Last Mile, Within Reason

Many connectivity incidents affect international capacity broadly, so switching from one Nairobi ISP to another won't necessarily help if both are relying on the same affected cable routes. That said, having a secondary connection — a 4G/5G router as backup to fibre, for instance — is still worth it for the everyday outages that have nothing to do with submarine cables: a fibre cut by a construction crew on your street, a power problem at your ISP's local node. A simple failover setup, even a basic mobile router with a separate SIM, is inexpensive relative to the cost of a day of downtime and is something most small offices can set up without specialist help.

Practical setup for small offices

A dual-WAN router that can automatically switch between your primary fibre connection and a mobile data backup is a modest, one-time cost. For a small office, shop, or clinic, this is usually a more sensible investment than trying to negotiate enterprise-grade SLAs you don't have the leverage or budget to enforce anyway.

Design Your Software to Tolerate Delay, Not Just Failure

Most small business software is built with the assumption that the internet is fast and always available, and it fails ungracefully the moment that assumption breaks — spinning forever, losing data entered mid-transaction, or crashing. If you or your developer are building or customising systems for your business, it's worth explicitly designing for degraded connectivity: queue transactions locally and sync later, show the user a clear "pending, will retry" state instead of a frozen screen, and avoid designs that require a live round-trip to a server for every single action. This is unglamorous engineering work, but it's the difference between a business that limps through a bad connectivity day and one that stops functioning.

What to ask your software vendor

If you're paying for point-of-sale, invoicing, or accounting software, ask the vendor directly: what happens when the internet is slow or unavailable for an hour? Can the system work offline and sync later? Vendors who have thought about this will have a clear answer. Vendors who haven't will tell you it "shouldn't happen" — which is not the same as a plan.

Have a Manual Fallback That Your Staff Actually Know

Before mobile money and cloud software, Kenyan businesses ran on paper receipt books and manual ledgers, and those methods still work when the network doesn't. A simple written procedure — how to record a sale manually, how to reconcile it once systems are back, how to handle a customer whose M-Pesa payment hasn't confirmed yet — costs nothing and should be something your staff have actually practiced, not just a document in a drawer. The businesses that cope best during an outage are usually not the ones with the most sophisticated technology; they're the ones where the till operator or receptionist knows exactly what to do without having to call the owner.

Think About Where Your Backups Live

If your only backup of critical business data is in a cloud service reachable only over the internet, a connectivity incident that coincides with a local hardware failure — power surge, theft, laptop damage — leaves you with no way to recover anything until the network improves. Keeping a periodic local copy of critical data, even something as simple as an encrypted external drive updated weekly, is a cheap insurance policy against the unlikely but painful scenario of two problems hitting at once.

A Word on Budget and Priorities

None of this requires a large budget, and you should be suspicious of anyone trying to sell you an expensive "enterprise resilience" package before you've done the basics. For most SMEs, SACCOs, and small agencies in Kenya, the sensible order of priorities is: get a cheap backup connection for everyday local outages, ask your software vendors hard questions about offline behaviour, write down a manual fallback procedure and actually train staff on it, and keep a local copy of your most critical data. These four things cost relatively little in KES terms compared to even a single bad day of lost sales, compliance exposure, or customer trust — and unlike a submarine cable thousands of kilometres offshore, they are entirely within your control.

Connectivity incidents affecting East Africa are not a hypothetical risk to plan for someday — they are a recurring, physically explainable feature of how this region connects to the global internet, and they will happen again on a timeline nobody can predict. The businesses that handle them well aren't the ones with the most expensive infrastructure; they're the ones that accepted this reality early and built boring, practical fallbacks before they needed them.

Want this handled for you?

We build AI agents and automation for Kenyan businesses — and the infrastructure underneath them. Run the automation scan and find out what's worth building first.

Run the Automation Scan < Back to Blog
SYSTEM INITIALIZATION...

We Engineer Certainty.

GeekforGigs isn't just a consultancy. We are a specialized unit of Cloud Architects and DevOps Engineers based in Nairobi.

We don't believe in "patching" problems. We believe in building self-healing infrastructure that scales automatically.

The Partnership Protocol

We work best with forward-thinking companies tired of manual deployments and surprise AWS bills.

We embed ourselves into your team to automate the boring stuff so you can focus on innovation.

Identify Target Objective

Current System Status?

Where's the manual work happening?

What are you using to manage it today?

> SCAN COMPLETE
AUTOMATION OPPORTUNITY: —

Establish Uplink

Mission parameters received. Enter your details to initialize the request.