HTTP 424 Failed Dependency – Free, Online, Private

What HTTP 424 means

424 says the method was not executed because a previous method in a dependency failed. WebDAV uses it inside multi-status results: one operation failed, so a later one that depended on it was not attempted. It is not the status of the original failure. The original failure has its own code. 424 is the downstream consequence.

424 Failed Dependency belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 424

When you see HTTP 424 Failed Dependency, stop on that exact status line. 424 Failed Dependency means this action was refused because another action it depended on failed. The trace that usually produces it: A WebDAV PROPPATCH failed one property and the dependent property was not set. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 424 when you skip work because something it required did not succeed. Point at the dependency that failed. Do not use 424 as a wrapper around every error in a batch. The first error should wear its own status. The dependents wear 424.

How to fix HTTP 424

To fix HTTP 424, change the condition that made the server choose Failed Dependency. Find the failed dependency and handle that status. Do not treat 424 as the root cause. Do not retry the dependent call alone. Retry the whole dependency chain after the root failure is fixed. An isolated retry of the 424 call is not enough. If the log line is a different code, leave this page. The mix-up people make with 424 is this one: The root failure might be 409, 403, or 422. 424 only means 'I did not try, because that other thing failed'. 207 can wrap both.

• A batch API skipped step two after step one returned 409.
• The body did not name the failed dependency, so the client retried the dependent call forever.
• A server returned 424 for the root failure and the real cause was lost.

An access log that only stores 424 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 424 Failed DependencyHTTP/1.1 424 Failed Dependency
Content-Type: application/json

{"dependsOn":"step-1"}

The JSON names step-1. The client looks up step-1, fixes that error, and runs the batch again. Retrying only the 424 step will fail the same way if the dependency is still broken. In WebDAV the surrounding status is often 207.

What the client should do

Find the failed dependency and handle that status. Do not treat 424 as the root cause. Do not retry the dependent call alone.

Do not cache 424 as the resource. It describes a skipped action.

Retry the whole dependency chain after the root failure is fixed. An isolated retry of the 424 call is not enough.

Codes people confuse with HTTP 424

The root failure might be 409, 403, or 422. 424 only means 'I did not try, because that other thing failed'. 207 can wrap both.