# Redundancy is not a luxury. It's a position.
Two days ago, Microsoft's email infrastructure went down. Not a hiccup — a real outage. Businesses that run on Outlook and Microsoft 365 couldn't send, couldn't receive, couldn't function. Calendar invites vanished. Sales teams went quiet. Support teams couldn't respond. Entire organizations sat on their hands and waited for someone in Redmond to fix the problem.
My email didn't go down. I use Google. That's not because Google is inherently superior or because I saw this coming. It's because my communication infrastructure doesn't depend on a single vendor. And that decision — which I made years ago for reasons that had nothing to do with this specific outage — meant that Tuesday was a normal workday for me and a crisis for a lot of people I know.
That's what redundancy does. It turns someone else's emergency into your regular afternoon.
The question isn't whether your critical systems will fail. It's whether you've decided in advance what happens when they do.
You already understand redundancy
You already practice redundancy everywhere. You just don't call it that.
There are four people in my family. We have sixteen plates in the cupboard. Nobody looks at that and thinks we're being wasteful or paranoid. We don't sit around justifying the existence of plate number nine. It's just... how a household works. You have capacity beyond the minimum because the minimum assumes nothing ever breaks, nobody ever visits, and you never need to run the dishwasher at an inconvenient time.
Same logic in the pantry. Soup cans. Extra milk. More bacon than you technically need for Saturday morning. You're not hoarding — you're maintaining a buffer between "everything is fine" and "we have a problem." That buffer is redundancy. It's the gap between what you need right now and what you'd need if something changed without warning.
And then there's power. The little UPS plugged into the wall behind your desk — the power goes out and your router stays on, your computer stays on, you don't even notice for twenty minutes. Scale that up and it's a Tesla Powerwall on the side of your house, storing energy from your solar panels so the grid going down doesn't mean your lights go out. Scale it up further and it's a powerpack behind a hospital — stored energy ready to take over the moment the grid fails. Different scale, same principle: a secondary source that's already there, already charged, already ready, so that when the primary fails the system doesn't ask permission. It just keeps running.
That's the spectrum. A $150 box from Best Buy. A battery on your garage wall. A powerpack behind a hospital. A redundant flight computer on a SpaceX rocket. The engineering is different. The question is always the same: what happens when the primary source goes away?
When failure is not an option, redundancy is the design
Every critical system on a SpaceX rocket has a backup. Flight computers, navigation, communication, engine control — the systems that keep people alive and the mission on course are doubled or tripled. Not because SpaceX expects failure. Because SpaceX accepts that failure is possible and designs around that acceptance.
They don't hope the flight computer works. They build two. If one fails, the other takes over. Seamlessly. Mid-flight. At 17,000 miles per hour. The astronauts might not even know it happened.
That's not pessimism. That's engineering maturity. The people who build the most ambitious systems in the world are also the people who most aggressively plan for those systems to break. There's no contradiction there. There's a lesson.
And the lesson scales all the way down. You don't need to be launching rockets. You need to be running a business where email going dark for 48 hours doesn't paralyze your entire operation. The stakes are different. The principle is identical: if the system matters, the system needs a fallback.
A backup is a snapshot of your ability to function
Think about what it means to back up your computer. You're not duplicating the machine — you're saving a state. A snapshot of everything that matters, frozen at a point where it was current and correct. If the machine dies tomorrow, you don't start from nothing. You start from yesterday. The gap between "total loss" and "minor inconvenience" is that saved state.
That same idea applies to every system your business depends on.
Your email goes down? If you've got a backup email path — even a basic Gmail account that can send on behalf of the business — you've saved your communication state. You can still reach people. You can still respond. It's not as polished as your normal setup, but it works. You're operating from yesterday's backup instead of staring at a blank screen.
Your project management tool goes offline? If your current task list exists somewhere else — even a shared document, even a printed sheet from last Friday — that's a backup. A snapshot of the work that was true before the failure. Not perfect. Not real-time. But enough to keep moving.
Redundancy isn't about duplicating everything. It's about saving the state of your ability to function so that when one system fails, you can restore from the last known good position. Just like the battery backup behind your desk — the power goes out, and you keep working. The transition should be boring. That's the whole point.
Redundancy isn't paying for two of everything. It's having enough plates in the cupboard that a broken one doesn't cancel dinner.
Single points of failure look like efficiency until they don't
Most businesses have more single points of failure than they realize, because the failures haven't happened yet. And when everything works, a single point of failure looks exactly like a smart decision. One vendor. One bill. One login. One system to learn. Clean. Simple. Efficient.
Until it's not.
One email provider. One internet connection. One payment processor. One phone system. One person who understands the billing software. One laptop with the only copy of the file. One DNS provider.
Each of those is a bet. You're betting the thing won't go down, or that if it does, you can wait it out. Sometimes that's reasonable — the probability is low and the cost of a fallback is high. But most of the time, people aren't making a conscious bet. They just never thought about it. They picked one vendor, set it up, and moved on.
That's not a strategy. That's an assumption you never revisited.
SpaceX doesn't look at a flight computer and say "well, it's probably fine." They look at it and say "what happens when this one fails?" The answer is never "we hope it doesn't." The answer is always another system, already running, already tested, ready to take over.
Your email isn't a flight computer. But if your business can't function without it — and most can't — then the question is the same.
The Microsoft outage wasn't unusual — it was the flat tire
I don't mean someone predicted this specific outage on this specific date. I mean that large-scale service disruptions are a known category of event. They happen. Microsoft has had them. Google has had them. Amazon Web Services has had them. Cloudflare, Slack, Zoom — every major platform has had significant outages in the last few years.
This isn't controversial. It's a pattern. And yet most businesses plan as if their primary tools will be available forever. When the outage hits, the response is shock and frustration, as if something unprecedented occurred.
It wasn't unprecedented. It was the thing that always eventually happens. You don't act surprised when you get a flat tire. You might be annoyed, but you're not shocked. Tires go flat. Services go down. The only question is whether you've got a spare in the trunk or you're calling for a ride.
The vendor is not your contingency plan
When Outlook went down, people were checking Microsoft's status page. Refreshing Twitter. Waiting for the "we're aware of the issue" post. And then waiting some more.
That's fine as information gathering. But it's not a contingency plan. You have zero control over when Microsoft fixes their infrastructure. Zero. You can't call someone. You can't escalate. You can't pay extra to get fixed faster. You're a passenger, the pilot is unconscious, and your job is to sit there and hope.
I don't like that position. You shouldn't either.
A contingency plan is what you can do — with your own resources, on your own timeline — to keep operating while the vendor sorts out their mess. It might be ugly. It might be manual. It might involve an account you set up two years ago and never touched. But it's yours, and it works, and when the primary fails, you're reaching for a clean plate instead of eating off the counter.
The cost of downtime is almost always underestimated
What I heard from people during the outage: "We couldn't do anything." Not "we were slightly slower." They couldn't function.
Every hour a sales team can't send email is pipeline that stalls. Every hour a support team can't respond is a customer reconsidering whether they should've gone with your competitor. Every hour operations can't coordinate is work that doesn't move. Every hour invoicing is frozen is cash flow that isn't flowing.
Most businesses have never actually calculated this number. They should. Take your daily revenue, divide by working hours, multiply by the number of hours your team would be completely stuck without email. That's your exposure. For a lot of companies, even a single day of downtime means tens of thousands in delayed revenue, missed opportunities, and customer damage.
Now compare that to the cost of maintaining a backup email capability. A few extra accounts. A documented procedure. An hour of setup. The math isn't close. It's like comparing the cost of four extra plates to the cost of telling your guests to eat with their hands.
Build the backup shelf before you need it
Try this. Thirty minutes. Could save you days of chaos.
- List every tool your operation depends on daily. Email. Calendar. Files. Phone. Payments. CRM. Project management. Accounting. Website. DNS.
- For each one, ask: if this disappeared for 48 hours starting right now, what would we do?
- If the answer is "nothing — we'd wait," that's a single point of failure. Decide whether the risk is acceptable or build a fallback.
- Document the alternative. Write it down somewhere that doesn't depend on the system that might fail. Paper works. A shared drive on a different platform works. Your phone's notes app works.
- Test it once. Send an email from the backup account. Open the fallback file. Make sure the phone tree connects. Redundancy you've never tested is hope, not infrastructure.
You stock your pantry before the storm, not during it. You plug in the battery backup before the power goes out. You build the second flight computer before launch. Same principle, different altitude.
The spectrum runs from plates to rockets
That's the beautiful thing about redundancy — it scales. The principle is the same whether you're talking about extra plates in a kitchen cupboard, a UPS behind your desk, a Powerwall on your garage, a powerpack behind a hospital, a backup email domain for your business, or triple-redundant guidance systems keeping humans alive in orbit.
Solar feeds batteries like grid power feeds a hospital powerpack like a backup email feeds your communication when the primary dies. The source changes. The logic doesn't. The question is always: what happens when the primary fails? And the answer should never be "we find out."
The household version is instinctive. Nobody teaches you to keep extra soup. You just do it because you understand — without anyone explaining it — that the minimum is not enough.
The business version should be just as instinctive. But for some reason, companies that would never run out of coffee in the break room will run their entire communication infrastructure on a single vendor with no fallback and call it a strategy.
Apply the pantry logic to your business. Apply the battery logic to your critical systems. Apply the SpaceX logic to anything where failure means your customers, your team, or your revenue comes to a stop.
That's all redundancy is. It's the discipline of being ready for the thing you hope doesn't happen.