Don't let one single failure close down the shop

On Thursday September 3, 2026, Microsoft Azure experienced an infrastructure hiccup in its East US region. Over the ninety minutes that followed, ChatGPT, Claude, Grok, and Microsoft’s own Copilot all suffered severe performance degradation or outright outages simultaneously. Tens of thousands of reports flooded Downdetector. OpenAI reported elevated error rates across fifteen ChatGPT components and four Codex endpoints.

Writing in Computer Sweden, veteran cloud architect David Linthicum noted that this incident ought to terrify IT executives. And he is right—though perhaps not quite for the reasons the boardroom thinks.

Here were four fierce commercial competitors, each burning through billions of dollars to prove that their models and orchestration are distinct, superior, and proprietary. Yet when the curtain was pulled back by a routine regional glitch, they all stumbled over the exact same crack in the pavement. They shared the same underlying regional dependency. They shared the same failure domain.

If your entire business operation halts because four "competing" AI providers all collapse when one datacenter on the American east coast gets warm, you have not built an AI-driven enterprise. You have built an elaborate hostage situation.

The single point of failure trap

For fifteen years, the tech industry has been sold a fairy tale about the cloud. Move everything off-premise, they said. Outsource your compute, your database, your authentication, your CRM, and now your cognitive layer. The cloud provider has thousands of site reliability engineers; you only have three. Why would you ever run your own iron?

Because of the failure domains.

When an internal server dies in your own rack or office, it is an incident you can see. You know which cable was bumped, which drive threw SMART errors, or which daemon ran out of memory. The system is bounded. It is managed by people who work for you, on hardware you can touch, with dependencies you can list on a single whiteboard.

When the cloud dies, you are sitting in the dark staring at a status page that insists "All Systems Operational" while your phone rings off the hook. You have adopted a sprawling, invisible cascade of third-party, fourth-party, and fifth-party dependencies that no one on your team designed, no one can inspect, and no one can fix.

Your SaaS helpdesk relies on a vendor whose backend runs on AWS, which calls an LLM hosted on Azure, which routes traffic through Cloudflare, which depends on a DNS provider that just had a route leak. When that chain snaps, an SLA payout does not save you. An SLA is just a coupon for a ten percent discount on next month’s bill while your business bleeds revenue in real time.

Always think forward: if this breaks, how do I fix it?

The foundational rule of engineering has not changed since the telegraph: always think forward.

Before you deploy any service—before you hook your customer communications or your deployment pipeline to an external API—you must ask the unglamorous question:

"When this external pipe goes dead—not if, but when—how do we keep the shop open?"

If the honest answer is "we stop working and wait for a tweet from an API status bot," you have failed the architecture test.

Resilience is not buying an expensive multi-region enterprise tier from the same cloud provider that failed. Resilience is local backups and local fallbacks. It is having an architectural plan for graceful degradation where losing external connectivity drops your efficiency by twenty percent instead of closing your doors entirely.

"But AI can only run in the cloud!"

The standard pushback from teams building modern agentic workflows is that AI is special. They argue: "We can't do local fallbacks. Frontier models take hundreds of gigabytes of VRAM and massive GPU clusters. We have to call the cloud API."

That was an acceptable excuse in 2023. In 2026, it is just intellectual laziness.

Building local fallback for AI workflows can be challenging, but it is far from impossible. More importantly, smaller models (SLMs) have improved at a staggering rate. The gap between what a 400-billion-parameter cloud giant does and what a quantized 8B, 14B, or 32B model can do on local hardware has shrunk dramatically for defined, structured tasks.

You do not need a frontier model to run a business. You only need a frontier model when you ask poorly formed, boundless questions.

The customer service bot: dumb models do smart work

Consider customer service. Companies routinely pipe their support queries directly into flagship cloud models costing twenty dollars a million tokens, routing through three tiers of cloud proxies. And what is that bot actually asked to do?

• "Where is my package?"
• "What is your return policy for open-box items?"
• "How do I reset my two-factor authentication?"
• "What are your opening hours on Midsummer?"

It is not synthesizing quantum mechanics. It is reading your FAQ, your documentation, and your order status database, and presenting the answer in clear, polite language.

A customer service bot can easily run on a compact, focused model—running locally on a quiet workstation, a small on-premise server, or an edge box. When paired with standard retrieval (a local vector store, SQLite full-text search, or BM25), a small model grounded in your actual documents will give accurate, factual answers without hallucinating.

And when the cloud giants go dark on a Thursday morning, your support desk doesn't throw up an ugly 503 Service Unavailable error. It keeps answering questions, processing returns, and looking up tickets. Your customers never even notice that half the internet just caught fire.

Coding and scaffolding: you still know how to code, right?

Then there is software development. The latest generation of AI-assisted engineering tools has made developers fast. But it has also fostered a strange, fragile helplessness.

What are developers actually using these models for eight hours a day? Scaffolding. Generating boilerplate. Writing repository interfaces. Setting up migration files. Drafting unit tests. Converting schemas. Looking up standard library syntax.

A modern, compact model running locally via Ollama or llama.cpp handles code scaffolding exceptionally well. It knows Python, Go, TypeScript, PHP, SQL, and Bash. It knows how to stub out an HTTP endpoint, format a JSON payload, or construct a regex. You do not need an active broadband uplink to an Azure datacenter in Virginia just to generate a boilerplate database migration.

And this brings us to the uncomfortable question that every engineering team needs to look in the mirror and answer:

You still know how to code, right?

If an API outage at OpenAI or Anthropic brings your engineering department to a complete standstill—if your developers literally cross their arms and say "the model is down, we can't ship"—you do not have an engineering team. You have an assembly line of prompt operators who are entirely dependent on someone else's server room.

Engineering craft is knowing how the software fits together. It is knowing how the operating system schedules processes, how memory is allocated, how the database indexes queries, and how the network routes packets. When the AI tools are online, use them to move fast. But when they stutter or go offline, your developers should be able to open a text editor, write the code, run the compiler, and ship the fix.

Don't let one single failure close down the shop

The lesson of September 3 is not that the cloud is evil or that you should throw all your SaaS contracts in the bin. The cloud is a tool of convenience. But convenience becomes a trap the moment it becomes your single point of failure.

If you want to sleep soundly at night, design your operations around three core principles:

1. Map your actual dependencies. If four of your critical SaaS vendors all rely on the same cloud region or the same model API, you do not have redundancy. You have four doors leading to the same burning room.
2. Build local fallbacks. Keep local copies of critical data. Keep local backups that are immutable and tested regularly. Ensure your core applications can run in a degraded, standalone state when outside networks fail.
3. Embrace compact local AI. Use local models for the tasks they are good at—document Q&A, basic triage, routine code generation, and data filtering. Keep a local inference pipeline warm so that if external APIs fail, your fallback is automatic.

Technology will always fail. Fibres get cut, power grids surge, deployment scripts push bad configs, and hyperscaler regions go offline.

When that happens, let your competitors spend the morning refreshing Twitter status feeds and posting apology notes to their customers. Keep your fallbacks ready, keep your fundamentals sharp, and never let a single failure close down your shop.