A water-utility agent's outage-reporting workflow fails for every resident after a downstream permit-status API it depends on goes offline, rather than only failing the specific requests that call that API. How should the on-call team classify this incident?
Select an answer to reveal the explanation.
Short Explanation
Think of one broken link in a chain that's only supposed to affect a single task, but instead drags the whole assembly line to a stop — that's a cascade. The permit-status API going down shouldn't have taken outage reporting with it if the workflow were properly isolated. Spotting system-wide failure from a single dependency is the tell.
Full Explanation
A cascading failure occurs when a single downstream dependency's outage propagates beyond its own scope and brings down functionality that shouldn't depend on it, usually because error handling or fallback paths weren't isolated per dependency; the fix is decoupling — circuit breakers, graceful degradation, fallback responses — so one dependency's outage degrades only the features that actually need it. An isolated tool error would only affect requests that call the permit-status API directly, not the entire outage-reporting flow, which is the mismatch here. A reasoning loop describes repeated re-invocation without ever resolving, not a hard system-wide outage triggered by a dependency going down. Drift describes gradual content-quality decay over time, not a sudden outage tied to one dependency failing. Caveat: telling a cascade from a true isolated error requires checking whether unrelated workflows are also affected, not just the one that surfaced the complaint. Operational check: review whether outage reporting calls the permit-status API directly on its critical path or only for a specific sub-feature, and add a fallback so unrelated requests keep working.