424 Failed Dependency

A WebDAV method could not be performed because an earlier, required action in the same request failed.

4xx Client ErrorDefined in RFC 4918 §11.4Get a live 424

What 424 means

RFC 4918 defines 424 for WebDAV operations that depend on another action succeeding first: when that prerequisite action fails, every dependent action is reported as 424 rather than being attempted at all. It most often appears inside a 207 Multi-Status response, where a compound method like PROPPATCH sets several properties in one call and an earlier property-set failure causes the rest to be marked as failed dependencies instead of being applied.

In real deployments this shows up in WebDAV-based calendaring and contacts sync clients (CalDAV, CardDAV) and in any batch WebDAV operation, such as a MOVE or COPY that touches multiple sub-resources, where an early failure in the batch invalidates steps that were conditioned on it succeeding.

Outside WebDAV-specific ecosystems, 424 is uncommon. Most general-purpose REST APIs express "this failed because a prior step failed" using a custom error code, a 409 Conflict, or a 400 Bad Request instead, since 424 is tightly coupled to WebDAV's multi-status, atomic-operation model rather than being a general-purpose HTTP concept.

Common causes

A PROPPATCH request sets several properties atomically, and an earlier property-set operation failed, so later ones are reported as 424.
A batch WebDAV operation, such as MOVE or COPY across multiple sub-resources, fails because an earlier dependency in the same request did not succeed.
A calendaring or contacts sync client issues a compound operation where one sub-request's failure cascades to every dependent sub-request.
Server-side transaction handling rolls back dependent steps after detecting an earlier failure within the same multi-status batch.

How to fix a 424

If you are the client (browser user or API caller)

Inspect the 207 Multi-Status response body to identify which specific sub-request actually failed and why.
Retry the whole batch only after fixing the root failure that triggered the cascade of 424 responses.
Avoid bundling unrelated operations into one atomic WebDAV request when partial success would be acceptable.
Treat a 424 entry as a side effect of a sibling failure, not as an independent error to fix on its own.

If you run the server

Return clear, distinct status codes for every resource inside the Multi-Status body so clients can pinpoint the true root cause.
Document which operations are atomic or dependent so client authors understand the cascade behavior in advance.
Decouple genuinely independent operations into separate requests where possible, to avoid unnecessary 424 cascades.
Log the root failure separately from its dependent 424 failures to make server-side debugging faster.

Example

PROPPATCH /docs/spec.xml HTTP/1.1
Host: dav.example.com
Content-Type: application/xml

HTTP/1.1 207 Multi-Status
Content-Type: application/xml

<?xml version="1.0"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/docs/spec.xml</D:href>
    <D:propstat>
      <D:prop><D:owner/></D:prop>
      <D:status>HTTP/1.1 409 Conflict</D:status>
    </D:propstat>
    <D:propstat>
      <D:prop><D:displayname/></D:prop>
      <D:status>HTTP/1.1 424 Failed Dependency</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

Setting displayname depended on the owner property, which failed with 409, so it is reported as 424.

Try it live

Our free status responder returns a real HTTP 424 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/424