Third-Party API Outage Plan for Small Business

Somewhere in your software there is a list of outside services it cannot work without, and one of them is going to go down on a day you did not choose. The plan for that day is written in code, in advance, and it has four parts: detect the failure fast, with your own timeouts and alerts rather than the vendor's status page; degrade gracefully, so one broken feature does not freeze the whole application; queue the work that cannot complete, so orders and requests are held and retried instead of lost; and tell the customer something calm and true while it happens. None of this requires an enterprise budget. It requires deciding, before the outage, what your software does during one, because the alternative is that it decides by accident.

The short version

A dependency and a single point of failure are not the same thing. A dependency is a service you use. A single point of failure is a service you use with no plan for its absence. The vendor does not decide which one it is; your code does.
Even the giants go down. In 2017 a mistyped command took Amazon S3 offline for around four hours and broke thousands of sites that had assumed it could not blink. Your payment gateway, shipping calculator, and email sender are not sturdier than S3.
Degrade the feature, not the business. When one outside call fails, the right outcome is one dimmed capability and an honest message, not a frozen checkout or a spinning white screen.
Queue what you cannot finish. An order that arrives during an outage should be accepted, stored, and completed minutes later, invisibly. Losing it is a choice, made earlier, by whoever skipped the queue.
Detect it yourself. Your own timeouts, error counts, and alerts will know before the vendor admits anything. During the S3 outage, even Amazon's status dashboard could not update, because it depended on S3.
Write the one-page runbook. Who gets alerted, what gets switched off, what the customer message says, and who is allowed to declare it over. One page, printed before it is needed.

What actually happens when a critical API goes down?

The clearest lesson comes from the biggest example. On the morning of February 28, 2017, an Amazon engineer following a documented playbook entered one input incorrectly, and the command removed far more S3 servers than intended. Amazon's own post-mortem of the S3 outage lays out the result with unusual honesty: core subsystems had to be fully restarted, the outage ran roughly four hours, and a meaningful slice of the internet, sites and apps that had built on the assumption S3 was simply always there, broke alongside it. The detail worth framing is that AWS could not even update its own service health dashboard during the incident, because the dashboard depended on S3 too.

The point of the story is not that AWS is careless. It is close to the opposite: if the most heavily engineered storage service on earth can vanish for an afternoon over one keystroke, then the smaller services your business leans on, the payment gateway, the shipping rate lookup, the tax calculator, the email and SMS senders, the CRM's API, will certainly have their bad afternoons too. Their uptime is their responsibility, and it is genuinely out of your hands. What has never been out of your hands is your software's behavior during their downtime, and that behavior is decided in the thirty seconds after the first request times out. Software that was written with no opinion about failure will improvise one, and improvised opinions look like error screens on your busiest day.

This is the honest cost of the integrated stack we generally advocate for. Connecting your systems is still overwhelmingly the right move, for reasons we lay out in why API integrations beat copy-paste, but every connection is also a place where somebody else's Tuesday can become yours.

How do you find your single points of failure?

With a one-afternoon audit, and no code changes. List every outside service your software calls: payments, shipping, taxes, email, SMS, maps, auth, analytics, AI models, anything that leaves your building over a network. For most small business systems the list has fewer than a dozen entries, and only three or four sit on the money path.

Then ask one question per entry: if this call times out right now, what exactly does the customer see? Answer it by reading the code or by testing it, not by intuition. Any answer that begins with "I think" or "probably an error page" marks a spot where the work is. While you are there, capture three more facts per service: what the failure would cost per hour (a down payment gateway is measured in lost orders; a down analytics script is measured in nothing), whether the calls are reads or writes, which turns out to decide the whole strategy, and how you would find out it was failing, which for most systems today is the honest and uncomfortable answer "a customer tells us."

Sort the list by cost per hour and you have your priority order. Deep failure handling on every integration is over-engineering for most businesses; on the top three it is basic prudence. The same thinking applies one layer down, at the level of retries, timeouts, and rate limits, which our guide to API integration patterns covers with code.

What does graceful degradation actually look like?

Graceful degradation means the blast radius of a failure matches the size of the failed piece. One broken outside service should cost you exactly one capability, temporarily, and nothing else. In practice it looks different for reads than for writes.

For reads, serve something older or simpler instead of nothing. If the live shipping-rate lookup is down, quote your standard flat rates, marked as estimates, or the last rates you successfully fetched. If a product-review service is down, show the page without the reviews block rather than letting one embedded widget hang the render. A slightly stale answer with a caveat beats a spinner that never resolves, and the customer usually never notices the difference.

For writes, accept and hold rather than reject. This is the part most software gets wrong, because the natural failure of a synchronous design is to make the vendor's problem the customer's problem: the email service is down, so account signup throws an error; the invoicing API is down, so the order fails. The better shape is to record what the customer wanted, confirm it, and complete the outside call when the service returns, which is the queue we cover in the next section.

Two more behaviors separate a designed degradation from an accidental one. First, fail fast: a call that would hang for sixty seconds should be cut off after a few, because a slow failure ties up your whole system in waiting, and a page that hangs is functionally a page that is down. Second, stop calling a service that is clearly failing, the pattern engineers call a circuit breaker: after repeated failures, skip the call entirely for a cooling-off period, use the fallback immediately, and probe occasionally to see whether the service has recovered. It is less code than it sounds, and it is the difference between a hiccup and a pileup.

How do you avoid losing orders during an outage?

With a queue, which is a grand word for a simple discipline: write the request down somewhere durable before trying to complete it, and retry until it completes. When an order arrives and the fulfillment API is unreachable, the order is saved with a status of "pending sync," the customer sees a normal confirmation, and a background process retries every few minutes until it goes through. A store that says "your order is in, the confirmation email follows shortly" keeps the sale. One that throws a red error at the payment step loses it, over somebody else's bad five minutes.

Two details make a queue trustworthy rather than dangerous. Retries must be idempotent, meaning a request that gets retried three times produces one order, one invoice, one email, not three; this is usually a matter of attaching a unique key to each queued action so the receiving side can recognize a duplicate. And the queue needs a dead-letter end: after some number of failed attempts, an item stops retrying and lands in front of a human, because endless silent retrying is just a slower way to lose the request. Both mechanics, along with acknowledging fast and processing later, are the heart of our guide to webhooks that never lose an event, and the same patterns apply to any outbound call worth money.

The strategic point owners should take from this section: a queue converts an outage from lost revenue into delayed paperwork. That is the entire trade, and it is nearly always worth making on the money path.

How do you detect an outage before your customers do?

Assume the vendor's status page will be late. Status pages are updated by humans, under pressure, at companies having a bad day, and the S3 incident set the canonical example when the dashboard itself could not turn red. Your own software, meanwhile, knows the truth on the very first failed call. It just needs to be set up to say it out loud.

The setup is modest. Wrap outside calls so that failures and timeouts are counted per service, and alert when the count crosses a threshold, five failures in five minutes is a fine starting rule, sent to a channel someone actually watches. Log enough context that you can tell "their API is down" from "we shipped a bug," which mostly means recording the status codes and durations of outbound calls. Add a simple uptime check on your own critical flows, because from the customer's seat, your checkout being broken by a vendor is indistinguishable from your checkout being broken. None of this needs enterprise tooling; the whole stack fits a small app, as we show in observability for small apps.

Detection is also what makes the rest of the plan usable. Degradation and queues buy you time, but only if someone knows the clock has started. The businesses that handle outages well are rarely the ones with the fanciest infrastructure. They are the ones that found out at minute two instead of hour two.

What goes in a small business outage runbook?

A runbook is one page that removes every decision you would otherwise be making angry and in a hurry. Write it in an afternoon, in this order.

List your critical dependencies and their blast radius. Take the top entries from your audit and write, for each, what breaks for the customer when it is down. This is the map the rest of the page hangs on.
Name the first responder and the alert path. Who receives the automated alert, day and night, and who is second if the first does not acknowledge within fifteen minutes. In a small business this can be two names; it cannot be zero names.
Script the customer messages in advance. Write the calm banner for the website, the reply for support, and the social post, with blanks for the specifics. "Card payments are delayed right now, your order is saved and nothing is lost" written on a quiet Tuesday beats anything composed mid-incident.
Define the manual switches. Decide what can be turned off or swapped while the outage lasts: switch to the backup email provider, disable the live rate lookup and use flat rates, pause the marketplace feed. Each switch gets one line: when to pull it, how, and how to undo it.
Write the recovery drill. When the service returns, the queue drains; the runbook says who confirms it actually drained, who spot-checks that queued items completed once rather than twice, and who declares the incident over.
Rehearse it once. Pick a low-stakes hour and simulate: block the outbound call in a test environment and walk the page. Rehearsal is what turns the document from a comfort object into a plan, the same logic that makes an untested backup not a backup, as we argue in backups and disaster recovery for small businesses.

Keep it to a checklist you can act on with adrenaline in your bloodstream, because that is the state you will read it in.

Alert received and acknowledged, clock started
Confirmed it is the vendor, not our bug (check outbound error logs)
Degradation or manual switch engaged for the affected feature
Customer banner and support reply posted
Queue confirmed accepting and holding new work
Vendor status page and comms monitored for recovery
On recovery: queue drained, duplicates checked, banner removed
Ten-minute retro written: what we saw, when we knew, what to fix

Common pitfalls

The recurring failures in outage readiness are less about missing technology and more about missing decisions.

The all-or-nothing build. Software written as one synchronous chain, where the page waits on the vendor and the customer waits on the page. Nobody chose the freeze; it is just what an unhandled timeout does by default.

Trusting the vendor to tell you. Teams that rely on the status page or an email from the provider consistently learn about outages from customers instead. The first honest signal is always in your own logs.

Retrying without idempotency. A queue bolted on during the panic, without duplicate protection, and the recovery becomes its own incident: three charges, three confirmation emails, one very unhappy customer.

Here is a concrete case, details changed. An online retailer's checkout called a shipping-rate API live, on every order, to quote delivery costs. The integration was years old, worked flawlessly, and nobody thought of it as a risk. Then the rate service had a regional failure lasting most of a morning, and the checkout, which waited on the lookup with no timeout and no fallback, simply hung at the delivery step. Carts were abandoned at the exact moment customers had decided to pay. Worse, the team spent the first hour debugging their own code, because nothing told them the failure was external; the vendor's status page went yellow long after the morning was lost. The fixes, made afterward, were almost embarrassingly small: a three-second timeout on the lookup, a fallback to the store's flat-rate table marked as an estimate, an alert on repeated outbound failures, and a one-page runbook naming who flips what. Total effort was a few days. The next rate-service wobble, months later, cost them nothing but a banner, and most customers checked out against flat rates without ever knowing. The mispriced-shipping risk they had feared turned out to be pennies against the abandoned-cart losses of the frozen morning.

This kind of resilience work is not a separate product you buy; it is a quality of how your integrations are built, and it is part of every integration we take on as custom software work. Retrofitting it onto an existing system is usually days of work, not months, because the highest-value protections concentrate on the two or three calls that sit on the money path.

FAQ

What should my software do when a third-party API goes down?

Four things, decided in advance: cut the failing call off quickly with a short timeout instead of hanging; degrade just the affected feature, serving cached or simplified results for reads; queue writes durably and retry them with duplicate protection until the service returns; and show the customer a calm, honest message while it happens. The overall test is blast radius: one failed vendor should cost one capability for a while, never the whole application.

How do I know which of my integrations are single points of failure?

Audit them. List every outside service your software calls, then determine, by reading code or testing rather than guessing, what the customer sees if each call times out. Rank the list by revenue lost per hour of failure. Any service where a timeout produces a frozen page, a failed order, or a blocked signup, and which sits on your money path, is a single point of failure. Most small business systems have only three or four calls that truly matter, which is what makes the audit an afternoon rather than a project.

Can a small business really justify building outage handling?

For the top two or three dependencies, yes, and cheaply. Timeouts, a fallback response, an error-count alert, and a durable retry queue on the money path are each measured in days of work, not months, and a single protected outage on a busy day can repay all of it. The version that is not justified is uniform, deep resilience across every integration; an analytics script and a payment gateway do not deserve the same engineering, and spending as if they do is how these projects get a bad name.

Should I rely on the vendor's status page to detect outages?

No. Treat it as confirmation, not detection. Status pages are updated manually by teams mid-crisis and routinely lag the real failure, sometimes spectacularly: during the 2017 S3 outage, Amazon could not update its own health dashboard because the dashboard depended on S3. Your software experiences the truth on the first failed request, so detection belongs in your own logs, timeouts, and alerts, which will beat the status page by anywhere from minutes to hours.

What is graceful degradation in plain terms?

It is software that loses features the way a healthy business loses a supplier: inconveniently, visibly, and without stopping. When an outside service fails, pages still load, orders are still accepted, and the affected capability either runs in a reduced mode, estimated shipping instead of live rates, for example, or switches off with a clear note, while everything unrelated continues untouched. The opposite, where one vendor timeout freezes checkout or blanks the site, is accidental design, and it is the default unless someone decides otherwise.

What belongs in an outage runbook?

One page: your critical outside services and what each one breaks when it fails, who gets the alert and who is the backup, pre-written customer messages with blanks for specifics, the manual switches you can flip while it lasts (backup providers, fallback modes, paused feeds), and the recovery steps, draining the queue, checking for duplicates, declaring the incident over. Then rehearse it once against a simulated failure, because a runbook that has never been walked is a guess, and outage day is a bad day for guesses.

The Day a Third-Party API Goes Down: An Outage Plan for Small Business Software