Dependency Failure Drills: Testing What Breaks When One Service Stalls
Most site outages are not total. A page loads, a form hangs, a payment widget spins, or an image never appears. Small teams often plan for the dramatic case, a server that disappears entirely, and overlook the quieter failures where one upstream service stalls while everything else looks healthy. This article describes a drill you can run without special tools: list the dependencies behind your key pages, simulate a slow or missing response from each, and record what visitors would experience. The goal is not to predict every failure but to learn which dependencies deserve attention before a bad afternoon teaches you.
Start With a Dependency Inventory
Open your main pages in a private browser window and use the developer tools network panel to list every request the page makes. You will likely find your own origin, a content delivery network, fonts, analytics scripts, embedded video, a chat widget, a payment form frame, and perhaps an API for search or recommendations. Write each one down with the page it appears on and whether the page can render without it.
Separate dependencies into three groups. Blocking dependencies stop the page from being usable, such as the script that renders a checkout form. Degrading dependencies reduce quality but leave the page usable, such as a styling file served from a slow external host. Passive dependencies are invisible to visitors, such as analytics beacons. This classification determines how much attention each one deserves during a drill.
Designing the Partial Failure Test
For each blocking and degrading dependency, decide how you would simulate a failure. You can block a domain in your browser's developer tools, use a request-blocking extension in a test profile, or temporarily point a local hosts entry at a non-responding address on a test machine. Simulate a slow response as well as a dead one, because a hung connection often hurts more than a clean error. Browsers wait a long time on stalled requests by default, and visitors will assume the page is broken long before a timeout fires.
Run the same user journey each time: load the landing page, reach the login screen, submit a contact form, and add an item to a cart if applicable. Note what changes. Does the page render at all? Do buttons respond? Does a spinner stay forever? Are error messages understandable? Write results in a simple table with columns for dependency, journey step, observed behavior, and severity.
Questions to Ask About Each Dependency
A dependency inventory becomes useful when each entry is answered with a few plain questions. Who owns this service, and how would you learn about its outage? Can your page load its own code without it, or does a rendering path require it? If it fails, does a visitor lose data they just entered? Is there a documented way to disable the feature temporarily, such as a configuration flag or a way to remove a script tag through your site's theme or content settings? Who on your team is allowed to make that change at 2 AM?
Avoid assuming that a vendor's status page covers your exposure. It may describe a region or product you do not use, or it may lag behind what visitors actually see. Your own drill record is more reliable than a general claim about service quality.
A Short Checklist for Your First Drill
Keep the first drill small so it finishes within an hour. Pick two key journeys, typically the homepage to a conversion point and the login path. List every request each journey makes, then simulate failure for the three most suspicious entries: the one that loads slowest, the one that is most central to the journey, and the one you know least about.
Afterward, rank findings by visible impact. A blocked analytics script is rarely urgent. A stalled form submission that discards input is serious. Turn the most serious findings into specific tasks: remove the dependency from the critical path, add a visible fallback message, load the script asynchronously so it cannot block rendering, or document the manual disable procedure. Schedule the next drill for the following quarter, and repeat the exercise after any change that adds a new third-party tool, because each addition creates a new place where the chain can break.