How a dependency failure can spread through your app

Several parts of your application can fail for the same reason. A slow dependency may leave requests waiting, retries can add more work, and a shared queue or connection pool can become a bottleneck.

The sequence below is an illustrative scenario, not a customer incident or a report about any named vendor.

Editorial correction, September 11, 2026: an unsupported account of a July 2024 outage and response-time savings has been removed.

Follow the work that stopped completing

Imagine a checkout service whose payment requests have become slow. Pending requests occupy capacity for longer. If each caller immediately retries, the number of outstanding requests can increase while fewer purchases complete.

That extra work can affect other operations sharing the same resources. A delayed receipt does not necessarily mean the email provider has failed; the job may still be waiting behind the payment work.

Google's SRE chapter on cascading failures (opens in new tab) describes how overload, resource exhaustion and retries can reinforce one another. Its examples are useful when examining a failure chain in your own system.

Separate the trigger from the symptoms

Start with one affected user operation. Use its request records to find where time was spent, which attempts were retried and whether work reached the next service. Compare that sequence with queue depth and resource saturation.

Then check relevant vendor reports. Match their affected product, region and incident period to your own observations. A broad incident report is context for the investigation; it does not establish the cause of every local error.

Shared infrastructure deserves attention too. Check the resolver, network path or hosting region actually used by the failing operation. Your domain's authoritative DNS provider and the resolver used for outbound API requests are different roles; a diagram that puts every request behind the same vendor may be wrong.

Make recovery observable

Track completed operations as well as error counts. A vendor may have recovered while your application still has a backlog. Keep the original request, retries and final outcome connected so that repeated attempts are not mistaken for separate customer actions.

Your response depends on the operation's safety and constraints. Use its existing runbook for retry limits, deadlines and degraded behaviour. The rate-limit investigation guide covers the questions to ask before adding retries.

Record the relationship before the next incident

Add the failure chain to the affected operation’s runbook: which call slowed down, what retried it, and which shared resource became saturated. Link the request records and queue measurements that support that sequence.

Keep the vendor report, your observed failures and the recovery period as separate evidence. The status-page guide explains what each source can and cannot tell you.