424 Failed Dependency: Trace the Upstream Failure

Problem

You call an API, the request is well-formed, and back comes 424 Failed Dependency. Nothing you sent is wrong — no bad syntax, no missing field, no expired token. The server is telling you something more specific and more frustrating: it couldn’t do what you asked because another action it relied on failed first. Your request was collateral damage. The real error happened somewhere upstream, and 424 is the server pointing at it without naming it. Your job is to find what actually broke.

Symptoms

• The response status is 424 Failed Dependency, often with a body describing (or hinting at) a different, earlier failure.
• The same call sometimes succeeds — because the failure isn’t in your request, it’s in a dependency whose health varies.
• In batch or WebDAV operations, you see 424 attached to several sub-operations at once inside a 207 Multi-Status response, while one sibling shows a real error code.
• With managed AI agents and microservice gateways, a 424 surfaces when a tool call, downstream service, or backend the platform invoked returned an error of its own.

What This Error Actually Means

424 was defined in RFC 4918 §11.4, the WebDAV specification: “the method could not be performed on the resource because the requested action depended on another action and that action failed.” Its original home is the 207 Multi-Status response — when a WebDAV client issues a batch (a PROPPATCH, a COPY, a MOVE) and one instruction fails, every instruction that depended on it comes back as 424 rather than being silently skipped. It’s a way of saying “we didn’t even try this one, because the thing it needed already failed.”

Plain web servers don’t emit 424 on their own. What’s changed is that modern APIs and microservice architectures borrowed it as a general cascade signal: when the service you called can only finish if a downstream call succeeds — a payment authorization, an auth lookup, a tool invocation, another internal service — and that call fails, the service returns 424 to say “the dependency, not you.” That’s why you’ll hit it against platforms like managed AI agents (the agent tried to invoke your API and it returned a 404 or 401) or cost/reporting APIs that fan out to a backend.

Top 3 Causes

1. A batch step failed and took its dependents with it - In a WebDAV or bulk operation, one member of the request returned a real error (403, 409, 423 Locked, 500). Every operation ordered to depend on it is reported as 424. The 424s are noise; the one non-424 error is the signal.
2. A downstream service the API called is failing - The endpoint you hit is a front for other services. One of them — a database, an auth provider, a third-party API, an internal microservice — returned an error or was unreachable, and the front-end surfaced the cascade as 424. This is the dominant cause outside WebDAV.
3. A precondition or lock dependency wasn’t met - The action depended on a resource that’s locked (423) or in a conflicting state (409), so the server couldn’t proceed and reported the dependency failure as 424. Common with document-editing, provisioning, and stateful workflow APIs.

Diagnose with DechoNet

• HTTP Check confirms the endpoint really returns 424 and captures the response headers and body — which is where a well-behaved API names the dependency that failed. It also confirms the 424 comes from the origin API rather than a proxy or gateway rewriting the response, so you’re chasing the right layer.
• If the failed dependency is itself an HTTP endpoint you can identify from the body, run HTTP Check against that URL directly — a 401, 403, 404, or timeout there is the actual problem the 424 was pointing at. If the dependency is a hostname that won’t resolve, DNS Check confirms the upstream is simply unreachable by name.

Resolution Checklist

• Read the 424 response body first, not the status. A well-designed API embeds the real dependency error (the code, the service, or the resource that failed). That’s your starting thread.
• Identify the upstream action your request depended on. In a 207 Multi-Status batch, it’s the sibling member that returned a genuine 4xx/5xx. In a microservice, it’s the downstream call the endpoint fans out to.
• HTTP-check that dependency endpoint directly if it has its own URL. Reproduce its real status in isolation — that’s the error you actually have to fix.
• Fix the root cause the dependency reported: refresh the auth token, create the missing resource, release the lock (423), resolve the conflicting state (409), or restore the unreachable service. Then retry the dependent request.
• If you own the API returning 424, make sure its body carries the underlying error. A bare 424 with no dependency detail is nearly undebuggable for the caller and turns a two-minute fix into a support ticket.

When to Escalate

• If the 424 comes from a third-party or managed platform (a hosted AI agent, a SaaS API, a cloud service), the failing dependency is often inside their pipeline. Capture the request ID and the exact timestamp from the response and open a ticket — you can’t fix an upstream you don’t control.
• If a batch operation returns 424 for every member, the real failure is usually the first step in the sequence. Find that one; the rest are collateral and will clear once it succeeds.
• If 424s appear and disappear under load, the dependency is intermittently failing rather than misconfigured — treat it as a reliability problem in the downstream service (capacity, timeouts, connection pool), not a bug in the request.