Your server is running, the database responds, uptime monitoring shows green -- and the purchase still fails. The cause sits outside your own infrastructure: the payment provider stops answering, the shipping rate API runs into a timeout, a DNS record does not resolve, the CDN fails to deliver a file, a font host hangs or a review widget blocks page rendering. Across nine years of publicly reported outages, roughly two thirds (Uptime Institute) are attributable to external IT and data centre service providers -- cloud and internet giants, telecommunications, colocation. Availability therefore does not end at your own firewall, and a maintenance contract that only covers your own systems leaves the most common outage type untreated. This article shows how to build a dependency inventory, how to determine the blast radius of each dependency, which technical patterns absorb external disruptions and what a degraded mode looks like in which the shop keeps taking orders. Continuous observation of these external building blocks belongs in monitoring -- switching over during an incident belongs in emergency support.
The outage comes from outside
A modern online shop is no longer a closed system. Between the product page and the order confirmation sit a dozen external building blocks: payment providers and their 3-D Secure service, carriers with rate and label interfaces, address and tax validation, fraud detection, DNS operators, CDNs, an externally hosted consent script, review and chat widgets, marketplace and ERP connectors, plus the delivery of the order confirmation email. Every one of these runs on someone else's infrastructure, is operated by someone else's team, is updated during someone else's maintenance window -- and fails on someone else's schedule. The merchant carries the risk without access to either the cause or the repair timeline.
The scale of that risk is well documented. In the long-term analysis of publicly reported outages across nine years, the majority is attributable to external IT and data centre service providers (Uptime Institute). Within impactful outages, IT and networking problems most recently accounted for 23 percent (Uptime Institute); power remains the leading single cause. Encouragingly, outage frequency and severity have been falling for the fourth consecutive year (Uptime Institute) -- which does not make the remaining cases harmless, because a central provider takes many shops down at once.
Your maintenance contract does not end at the firewall
The cost side is equally clear. 54 percent (Uptime Institute) of surveyed operators put their most recent serious or severe outage above 100,000 US dollars, and one in five (Uptime Institute) above one million. For mid-size and large companies, a single hour of downtime costs more than 300,000 US dollars according to 90 percent (ITIC) of respondents; among organisations with more than 1,000 employees, 97 percent (ITIC) report costs above 100,000 US dollars per hour. These figures come from a large-enterprise context and cannot be transferred one to one to a mid-market shop; the underlying calculation can -- hourly revenue times outage duration, plus support effort and lost repeat purchases. How to quantify that for your own shop is covered in the article on downtime cost per minute.
Step 1: the dependency inventory
Resilience against external disruption starts with a plain question that surprisingly often goes unanswered: which external services does this shop need in order to accept an order? As long as that list does not exist, every incident begins as a search -- and searching is the most expensive activity during an incident. The inventory captures every external domain, every server-side API call, every script embedded in the browser and every incoming webhook, each with a classification: order-blocking, revenue-reducing or cosmetic.
Payment and fraud checks
Payment providers, 3-D Secure services, tokenisation, risk scoring. The area with the least room to manoeuvre: if it fails, the final step before revenue breaks.
Shipping and logistics
Rate lookups, delivery estimates, label creation, pickup point search. A hanging rate lookup blocks the cart even though the shop itself is healthy.
DNS, CDN and certificates
Name resolution, delivery of static files, certificate issuance and revocation lists. Disruptions here affect every page at once, not only the checkout.
Front-end scripts
Consent banners, reviews, chat, maps, fonts. A blocking script from an external source can stall page rendering even though it is functionally dispensable.
Connectors and back office
Marketplace links, ERP systems, stock and price synchronisation. Failures surface with a delay -- as wrong stock levels or as a backlog of unprocessed orders.
Notifications
Transactional email, one-time codes, push messages. An order without a confirmation creates support requests and cancellations even when it was captured cleanly.
The inventory is collected from three directions at once: from the code (which endpoints does the application call?), from the browser (which external domains does a product page and a checkout page actually pull in?) and from the network (which outbound connections appear in operation?). The front-end view comes almost for free with a Content Security Policy in report mode -- it logs every source a page attracts, including the ones nobody remembers adding. How to build such a policy is described in the article on HTTP security headers and CSP.
- Provider and endpoint: which service, which domain, which concrete call -- including whether it happens server-side or in the customer's browser.
- Purpose and criticality: order-blocking, revenue-reducing or cosmetic. This classification drives every decision during an incident.
- Timeout and retry: how long the call may take, how often it is repeated, and what happens afterwards.
- Fallback: which substitute logic applies -- a cached value, a flat rate, a second provider or a deliberate hiding of the element.
- Observation source: where the signal comes from that this service is degraded -- your own check, an error rate, the provider status feed.
- Contractual basis: contact person, committed availability, escalation path and response time -- at the provider and in your own SLA maintenance contract.
An inventory is not a document for the archive, it is a working basis. It changes with every plugin, every campaign and every new payment method, which is why it belongs in the regular maintenance rhythm rather than in a one-off onboarding project. The first survey regularly surfaces external domains that nobody deliberately embedded any more (project experience): leftovers from old campaigns, replaced widgets, test integrations that stayed live. Each of them is a dependency that takes effect during an incident without providing value in return.
Step 2: determine the blast radius
Not every external failure is an emergency. The blast radius describes how far the effect of a single failure reaches: does it stop the checkout, does it only degrade presentation, or does it affect the back office alone? That classification decides whether someone is woken at night or whether the case is handled on the next working day -- and it prevents the wrong problem from being tackled first.
| External building block | Symptom in the shop | Blast radius | Sensible mitigation |
|---|---|---|---|
| Payment provider | Payment method does not load, return breaks | Checkout stopped | Enable fallback payment method, capture the order |
| Shipping rate API | Cart shows no shipping cost | Checkout stopped | Flat rate per zone from your own data |
| DNS operator | Domain does not resolve | Shop unreachable | Second provider, longer TTL, registrar lock |
| CDN | Images and scripts missing | Presentation broken, purchase often still possible | Origin fallback, critical files served locally |
| Review widget | Empty area on the product page | cosmetic | Load asynchronously, hide on error |
| Marketplace connector | Stock and orders stop flowing | Back office, revenue impact delayed | Queue with resumption after the incident ends |
| Transactional email | Order confirmation missing | Trust and support load | Second delivery path, resend from the queue |
Two insights emerge almost inevitably from this exercise. First, usually only two to four building blocks are genuinely order-blocking -- everything else can be degraded without stopping revenue. Second, those critical blocks sit exactly where most abandonment happens even without an incident: with an average cart abandonment rate of around 70 percent (Baymard Institute), missing payment methods at 10 percent (Baymard Institute) and unexpected extra costs at 39 percent (Baymard Institute) are among the most frequent reasons for abandonment. A failure at that point acts as an accelerant on an already fragile path.
The blast radius is a business question, not a technical one
Step 3: technical mitigation
The most common weakness in handling external services is not a missing substitute but a missing patience limit. A call without a hard timeout waits until some default kicks in -- often somewhere between 30 and 60 seconds. Until then, every waiting request occupies an application process. At moderate traffic it takes only a few minutes until all processes are occupied and the shop is fully stalled, even though only a single external service is hanging. That turns an external partial disruption into a complete outage of your own -- and a cosmetic building block into an order-blocking one.
Hard timeouts
Set connect and read timeouts separately, in seconds rather than minutes. A shipping rate that has not arrived after 800 milliseconds will not arrive after 30 seconds either.
Circuit breaker
After a defined number of consecutive errors the call is no longer attempted for a time window and is routed straight to the fallback. That protects your own processes and gives the external service time to recover.
Queue instead of instant call
Everything that does not have to happen at the moment of purchase -- label creation, ERP handover, marketplace notification -- moves into a queue with retries and is processed once the disruption ends.
Server-side caching
Rates, tax values, stock levels or reviews are cached with a timestamp. If the source fails, the shop serves the last known value and flags it internally as stale.
Serve assets locally
Fonts, icons and core scripts belong in your own delivery. That removes an entire class of external dependencies from the critical path and helps with privacy and load time at the same time.
Idempotency
Every retry needs a unique transaction key so that a repeated payment or shipping request does not create a second booking. Without idempotency a disruption turns into an accounting problem.
These patterns only work together. A timeout without a fallback produces a fast error page instead of a slow one -- the sale is lost either way. A fallback without a circuit breaker keeps hammering a dead service every second and holds processes hostage. And a queue without idempotency produces duplicate bookings the moment the disruption ends and all waiting jobs run at once. The excerpt below shows what such a configuration can look like per external service -- the values are starting points, not prescriptions.
# External calls: patience limit instead of default
payment:
connect_timeout: 1.5s
read_timeout: 4.0s
retries: 1 # idempotent calls only
circuit_breaker:
error_threshold: 5 # consecutive errors
open_for: 60s # then one probe call
fallback: fallback_payment
shipping_rate:
connect_timeout: 0.5s
read_timeout: 0.8s
retries: 0
cache_ttl: 15m # last known rate
fallback: flat_rate_per_zone
reviews:
read_timeout: 0.6s
fallback: hide # cosmetic, no alertThe same principle applies in the front end with different means. External scripts belong in asynchronous loading, with a time limit, encapsulated so that an error does not stall the rest of the page. Particularly delicate are scripts that load further code themselves or change their delivery without notice -- that applies to consent solutions as much as to libraries on the payment page. How to notice such silent changes is covered in the articles on script drift in cookie banners and on script monitoring for payment pages.
Step 4: degraded mode instead of a lost sale
A degraded mode is a pre-described operating state in which the shop deliberately does less but keeps selling. It is the opposite of a maintenance page: instead of closing the store, the disrupted partial function is replaced or hidden. What matters is that the rules are settled beforehand -- which failure triggers which switchover, who is allowed to trigger it, how the customer is informed and when the shop switches back.
- Fallback payment method: if one provider fails, invoice, prepayment or a second provider is enabled. This requires those methods to be maintained and tested -- a payment method disabled for months is not an option during an incident.
- Shipping cost fallback: instead of the live rate lookup, a flat rate per zone from your own data applies. The cart shows an amount and the order path stays walkable.
- Accept the order, reconcile later: where an exact calculation is impossible, the order is captured and the difference determined after the disruption ends -- with clear information to the customer before they order.
- Switch off cosmetics: reviews, recommendations, chat and maps are hidden rather than displayed with an error. An empty area sells better than an error message.
- Asynchronous confirmation: if email delivery hangs, the order confirmation moves into a queue and is sent later instead of letting order completion fail.
- Visible notice: a short, factual notice in the checkout works better than silent substitute logic. A named limitation is accepted far more readily than one the customer discovers alone.
With degraded mode, the legal side belongs in from the start. Prices, shipping costs and delivery times are mandatory information; a flat rate must not put the customer in a worse position without them being able to recognise it before completing the purchase. Anyone planning a later reconciliation has to state it clearly in advance -- and have the wording reviewed legally if in doubt. In practice it pays to set fallback values generously in the customer's favour: the difference costs less than the abandoned purchase and far less than a later complaint.
A shop that keeps taking orders during someone else's outage loses margin. A shop that shuts down loses the customer -- and the margin along with them.
Step 5: make external disruptions visible
Most monitoring setups observe their own infrastructure in great detail and external services not at all. That leaves precisely the most common outage type unobserved. The remedy is unspectacular: external building blocks get their own checks, their own thresholds and their own alert path -- separate from the alerts for your own systems, because they call for a different response.
- Synthetic checks along the real order path: an automated run from the product page to the last step before the charge detects exactly those failures a status code is blind to. The setup is described in the article on checkout monitoring.
- Error rate per endpoint instead of HTTP 200: measure the share of failed responses per external endpoint and time window, plus latency as a percentile. A service that responds but fails every eighth request is degraded -- even though it is reachable.
- Provider status feeds: the status messages of the providers in use belong in the same alerting system as your own checks, machine-readable. They often arrive later than your own measurement but supply context and expected duration.
- DNS and certificates: resolution, response time and validity belong under continuous observation; signing, registrar lock and check intervals are described in the article on DNS maintenance.
- Front-end view: a check that loads the page like a browser notices a blocking external script. A pure server request does not.
- Queues and backlogs: the length and the age of the oldest message in each queue are the most reliable early warning signal for a back office disruption.
Part of these disruptions are not accidental but attacked. In the European threat picture, 77 percent (ENISA Threat Landscape 2025) of reported incidents were DDoS attacks, based on 4,875 (ENISA Threat Landscape 2025) incidents analysed between July 2024 and June 2025. Around the German federal election and the Munich Security Conference in February 2025 alone, the BSI registered 52 percent (BSI, 2025 report) more DDoS attacks than the long-term average. When such a wave hits a provider, your shop is affected without being the target -- one more reason to know the alternative path in advance.
The goal here is not completeness but attribution: during an incident it must be clear within minutes whether the cause lies in your own system or at a provider. That single question determines everything that follows -- an internal fault means intervening, an external one means switching over and communicating. The foundation for that is solid availability monitoring, as described in the article on uptime monitoring.
External disruptions need their own alert class
Step 6: clarify roles and response times
Technology alone does not resolve an incident. The most expensive delay regularly happens between detection and decision: everyone sees the alert, nobody switches over, because it is unclear who is allowed to. Human error accounts for nearly 40 percent (Uptime Institute) of the major outages of the past three years; 85 percent (Uptime Institute) of those arose because procedures were not followed or were flawed. That is a question of preparation, not of individual diligence.
| Role | Task during an external incident | To be settled contractually |
|---|---|---|
| Detection | Receive the alert, narrow down the cause: internal or external | Reachability, alert path, committed response time |
| Technical decision | Activate degraded mode, verify fallback, plan the switch back | Who may switch over without asking |
| Merchant decision | Approve the partial function, goodwill limits, pricing questions | Deputy and reachability outside business hours |
| Customer communication | Notice in the shop, reply text for support, status information | Who drafts, who publishes |
| Provider contact | Report to the provider, ticket, follow-up | Access to the provider's support, contract numbers |
| Follow-up | Switch back, reconcile, review | Deadline for the review, storage of the evidence |
This allocation belongs in the maintenance contract, not in a wiki. Concretely that means: a committed response time for order-blocking disruptions, a defined alert path outside business hours and a named authority to activate degraded mode without asking. Which response times are robust and which merely sound good is assessed in the article on response time SLAs in emergency support.
Step 7: the drill
A degraded mode concept that has not yet been triggered is an assumption. The drill turns it into a supportable statement -- and it is less demanding than it sounds: one external service is made artificially unreachable for a defined time window, and the response is measured. The direction matters: what is blocked is your own call, not the external service.
- Choose the window. A low-revenue period, announced within the team, with an abort criterion and a described way back.
- Create the disruption. The call to the external service is blocked or delayed on the staging environment or deliberately on one instance.
- Measure detection. How many minutes pass until the alert, and does the alert name the right building block?
- Measure switchover. Does the fallback take effect on its own? If manual action is needed: how long does it take, and does the responsible person find the instructions?
- Check the customer view. Is the order path walkable end to end, is the notice understandable, are prices and mandatory details correct?
- Check the switch back. Does the return path run cleanly, are queues processed, do duplicate bookings appear?
- Document the result. Detection time, switchover time, anomalies and the resulting adjustments -- the record doubles as maintenance evidence.
Two measurements deserve particular attention: time to detection and time to effective switchover. Both can be improved over time, and both translate directly into money. In an environment where 41 percent (ITIC) of large enterprises put an hour of downtime between one and more than five million US dollars, every quarter of an hour saved is a measurable amount -- proportionally smaller in the mid-market, but in the same ratio. The record of a drill is also usable evidence towards insurers and auditors, as shown in the article on maintenance evidence for cyber insurance.
Scope: what this is not about
External availability is frequently confused with neighbouring topics even though it calls for different measures. Drawing the line is not pedantry, it saves effort: an inventory with criticality and fallbacks is created in a manageable amount of time and takes effect immediately, whereas a complete business continuity programme is a project of its own.
- Not a backup and restore topic: a payment provider that does not answer has destroyed no data. Recovery point and recovery time belong to disaster recovery -- here it is about planned partial function with intact data.
- Not a load test: peak load examines your own scaling, not the availability of external services. The two complement each other but the measures differ; the load test for peak traffic answers a different question.
- Not attack defence in the narrow sense: filter rules protect your own site. When the provider is attacked, only your own alternative path helps -- not your own defences.
- Not a code supply chain question: compromised packages are an integrity problem and are covered in supply chain attacks on shop dependencies. Here it is exclusively about the availability of running external services.
Anyone who wants to build the organisational framework systematically does not have to invent it. The German Federal Office for Information Security describes the requirements for outsourced services in its IT-Grundschutz compendium, among others in the modules on the use of outsourcing (OPS.2.3) and on cloud usage (OPS.2.2); contractual and organisational points -- availability agreements, escalation paths, fallback scenarios -- are already laid out there in an ordered way (BSI IT-Grundschutz). For a mid-size shop a deliberately small selection from it is enough, matched to the inventory.
External availability in the maintenance contract
For the building blocks described here to become a lasting state, they need an owner and a rhythm. In a maintenance contract that comes down to three clearly nameable services -- not an add-on option, but the part that covers the most common outage type in the first place.
Maintained dependency inventory
Collection, criticality assessment and regular updating -- including the check whether an embedded external domain is still needed at all.
Degraded mode concept
Described switchovers per critical building block, stored fallback values, tested fallback payment methods and an agreed notice text for the checkout.
Provider alerts with response time
Your own checks and provider status feeds in the alerting system, thresholds per endpoint and a contractually committed response time for order-blocking disruptions.
The effort is distributed differently than many expect: most of it arises once, with the inventory and the concept, while the ongoing share is small -- upkeep on changes, review of alerts, one drill per year. The rate of change, however, stays high: the BSI counts around 119 new vulnerabilities per day (BSI, 2025 report), an increase of roughly 24 percent (BSI, 2025 report) over the previous period. External services update accordingly often, and every update can change behaviour at the interface. How to make announced changes, deprecated versions and webhook migrations plannable is described in the article on payment APIs in maintenance.
In practice, collection, concept and observation rarely sit in one pair of hands -- which is exactly why external disruptions are so often handled by improvisation. Bundled sensibly they belong together: inventory and alerts arise in monitoring, switchover and communication in emergency support with a defined response time, and the binding commitment in the maintenance contract with an SLA. Which further services are part of that and how they interlock is shown in the overview of maintenance services.
Sources and studies