What the Cloud Is Made Of

At 3 a.m. on Monday, August 10, someone cut a fibre optic cable in a back alley in south Calgary, trying to steal copper.

The irony is that there is no copper in a fibre cable. As scrap, the cable is worthless.

But the damage was done: thirteen neighbourhoods and thousands of people lost internet, TV and home phone, and it took six crews and more than twenty technicians to put right.

As a remote worker, reliable internet is not a convenience: it is my livelihood, and I was offline for 36 hours.

It is a surprise that such a critical pillar of our modern economy can be taken out for so long, so easily. Perhaps even more surprising is how rarely most of us encounter such errors.

Copper is at record prices, driven by electrification and the data centre build-out for AI. Bell logged 993 copper thefts on its own network in the first half of 2026, up 78% year over year. The internet runs on raw materials: every new data centre bids up the price of the copper further, until eventually that price is high enough for someone to bring bolt cutters to a residential alley.

For all the ways our world has become interconnected and digitized in recent years, one thing has not changed. It still runs on physical infrastructure. One break in the chain between an ISP and an end user takes out far more than a website.

The internet was out for 36 hours. But what if it was 36 weeks? Would the modern digital economy just grind to a halt?

It got me wondering: how could it be that it takes a team of 20 people 36 hours to fix a single broken cable? And is there anything software people can do about all this? I decided to find out.

Contents

• Is there anything in the cable worth stealing?
• Why does it take twenty people to fix?
• The blast radius
• Why now
• What we can actually do about it
• The thing under the abstraction

Is there anything in the cable worth stealing?

Almost nothing, actually.

The part carrying your data is a core of glass about nine microns across. With its cladding, one strand comes to roughly the width of a human hair. Everything else in the cable is packaging: gel-filled tubes, a steel or fibreglass rod to take the strain, thin yarn, a plastic jacket.

A single outside-plant cable bundles 144, 288, or 432 of those strands.

None of it is copper. Fibre has no scrap value whatsoever; one telecom manager described it as literally glass in a tube. Someone committed a crime to steal a very long piece of expensive sand.

Why does it take twenty people to fix?

You would think that splicing a new cable together couldn't take that long: maybe a couple of hours? But that is wrong by an order of magnitude.

First you have to find the break. An optical time-domain reflectometer fires a pulse down the fibre and reads what scatters back, locating the fault to within a few metres. That is the easy part.

Then you splice every strand, individually. Fusion splicing aligns two hair-thin fibres under a microscope and fuses them with an electric arc, which takes several minutes per strand.

A 288-strand cable at five minutes a strand is roughly twenty-four hours of splicing, for one cut, before you count access or testing. Ribbon cable and mass-fusion splicers cut that down by doing twelve strands at once. But the math misses the real problem: thieves do not cut neatly; they pull and saw and drag away whole spans. You are not splicing a break, you are rebuilding a segment, and you cannot splice anything until new cable is pulled through. Rogers says vandalism repairs take three to four times longer than ordinary faults. Either way the work is painstaking, and the only way to compress it further is more hands. That is why technicians were called in from as far away as Edmonton to help out.

Rogers promised full restoration by 10 p.m. Monday; that deadline came and went, and so did the one after it. My service returned at 3 p.m. on Tuesday, thirty-six hours after the cut, and the network was fully restored by 5 p.m.

Software fails in milliseconds and heals in milliseconds. Fibre fails in milliseconds and heals at the speed of a team of technicians kneeling in a trench welding together microscopic strands of cable.

The blast radius

Something like thirty thousand people live inside that eight kilometre wide outline. The neighbourhood I live in never made the official list, but my internet was down, which tells you how precisely these footprints are known.

The mobile networks got slow too. What happens when every household in a neighbourhood with no broadband tethers to a radio network that isn't ready? Mobile data towers often also rely on fibre, frequently the same fibre in the same conduit, so a failure in one system could cause a failure in the other. Hurricane Helene, for example, destroyed more than 1,700 miles of fibre in western North Carolina, which knocked out most of the region's cell towers. Sometimes when networks fail they fail catastrophically.

Why now

Copper has more than doubled in price since 2020, to record highs, driven by electrification and the data centre build-out for AI. Every new data centre bids up the price of the metal, and eventually that price is high enough that someone brings bolt cutters to an alley in Erlton.

Government has taken notice: The Bail and Sentencing Reform Act came into force on July 15, 2026, adding an aggravating factor for theft and mischief against essential infrastructure. Just twenty-six days before this outage.

What we can actually do about it

The International Cable Protection Committee counts 150 to 200 submarine cable faults every year, 70 to 80 percent of them accidents involving anchors and fishing gear. The most critical cables on earth are cut roughly every other day and you have never noticed, because on the routes that matter, someone built the redundancy. Nobody built it for your street.

One of the principal fallacies of distributed computing is that the network is reliable. As Murphy's Law would have it: if the network can go down, it will go down.

Martin Kleppmann draws a distinction in Designing Data-Intensive Applications: a fault is one component deviating from spec, a failure is the whole system stopping. Our job as engineers is to make sure our systems fail in ways that don't bring the whole system down. And that is generally the hard part about building distributed systems.

A few things worth considering:

Software should survive internet outages. This is the lever an application developer fully controls. Concretely:

• Cache the last good state for when the network goes offline.
• Queue writes locally with idempotency keys, so the retry after reconnection doesn't duplicate the write.
• Make non-critical dependencies non-blocking. Analytics, telemetry and feature-flag SDKs should time out fast and fall back to values bundled with the build.
• Stop putting a network round trip in front of local work. If a user cannot open a document already on their disk because auth has to phone home, that is a design decision, not a network problem.
• Give retries jitter and a ceiling. When the link comes back, every client in the neighbourhood reconnects in the same second.

Kleppmann has been working on a local first approach to software: data lives on the device, the network is optional, sync happens when it can, and concurrent edits merge instead of erroring.

Decide what "degraded" means before you need it. Every feature you ship is implicitly read-only, queue-and-sync, or dead when the network drops. If you haven't spent time thinking about this, it's probably dead when your internet goes out.

Build alerting into your infrastructure. The cable was cut just before 3 a.m. Police were not notified until 6:20. That is more than three hours before anyone could begin the repair. If you do not hear about the outage from your monitors, you will hear about the outage from your customers.

Test your assumptions. A failover that has only ever been exercised at 2 a.m. with no traffic on it is a hypothesis. Unplug the primary during business hours with people watching, and verify: how long until traffic moves, whether the backup holds real load, and whether it fails back cleanly when the primary returns. If it doesn't, fix that.

Satellites are not the escape hatch. A minor geomagnetic storm in February 2022 de-orbited 38 of 49 freshly launched Starlink satellites. And when a volcanic eruption severed Tonga's only submarine cable in January 2022, leaving the country offline for 38 days, the ash plume degraded its satellite links at the same time.

Modern clouds like AWS and GCP have incredible fault tolerance and redundancy built in, but even they fail. In October 2025, a race condition in DynamoDB's DNS automation took down AWS us-east-1 for about fifteen hours, and with it Snapchat, Fortnite, Roblox and Duolingo. The tech industry spent thirty years decentralizing the network and then recentralized every application on top of it.

That includes the emergency line. In fact, there is now a market for cloud-native 911 platforms, moving call handling out of the local dispatch centre and into somebody's data centre; Carbyne is one of the companies selling it. Wherever the call handling lives, the call still has to get there, and that means your last mile has to be intact. This is already a problem in Canada: when Rogers went down nationally on July 8, 2022, more than twelve million customers lost service, Interac stopped, and police forces across the country reported that people could not reach 911. The cloud moves the fragility but does not remove it.

The thing under the abstraction

I build software for a living, which means I have spent years designing systems that assume your internet is working. Monday was a good reminder of that old adage about what happens to people who make assumptions. We have moved work, money, medicine, romance, ordering pizza, and the ability to call for help onto an abstraction we named after weather, and that abstraction runs through a thread of glass the width of a hair, in a lane behind a cemetery, reachable by anyone at 3 a.m. with no particular reason to hurry.

So that is what the cloud is made of. Glass, and the hope that nobody will come looking for copper on your street.

Further reading

• Martin Kleppmann and Chris Riccomini, Designing Data-Intensive Applications, 2nd edition
• Kleppmann et al., Local-first software: you own your data, in spite of the cloud
• Ed Conway, Material World: The Six Raw Materials That Shape Modern Civilization
• CRTC, Assessment of Rogers Networks for Resiliency and Reliability Following the 8 July 2022 Outage
• Common Ground Alliance, DIRT Report
• International Cable Protection Committee, submarine cable fault statistics