Failed Dependency

Active

RFC 4918 §11.4•Since 2007•WebDAV, batch APIs, deployment pipelines, workflow engines

HTTP 424 Failed Dependency indicates the method could not be performed because the requested action depended on another action and that action failed. Defined in RFC 4918 §11.4 (WebDAV). Used for cascading failures in batch operations, dependency chains, and workflow steps where a prerequisite fails.

Description

The 424 Failed Dependency status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. The dependency relationship is explicit: action B required action A to succeed first, and action A failed, so action B cannot proceed.

Originally defined for WebDAV operations on collections. When a COPY or MOVE of a directory fails on one member resource, other members that have a dependency on the failed resource also fail with 424. For example, copying a folder where file A fails — files B and C that reference file A receive 424 because their integrity depends on A being present at the destination.

The key distinction from other 4xx codes: 424 does not mean the request was malformed (400), the resource state conflicted (409), or something unexpected broke (500). It specifically communicates that a prerequisite operation in a dependency chain failed, making the current operation impossible. The client's request for this specific resource might be perfectly valid in isolation — it fails only because something it depends on failed first.

Outside WebDAV, REST APIs have adopted 424 for batch operations where one item's failure cascades to dependent items, deployment pipelines where a build step fails causing downstream deploys to abort, and workflow engines where step N depends on step N-1 completing successfully. The semantic is clean and unambiguous: cascading dependency failure.

When returning 424, the response body should identify which dependency failed and why. The client cannot fix the 424 directly — they must fix the root cause (the original failed dependency) and retry the entire operation. This makes 424 fundamentally different from 409, where the client can resolve the conflict and retry just that request.

Examples

WebDAV COPY of a collection — dependent member fails

http

COPY /webdav/project-folder/ HTTP/1.1
Host: files.example.com
Destination: /webdav/backup/project-folder/
Depth: infinity
Authorization: Bearer token123

Multi-Status response with 424 on dependent resources

http

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

<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:">
  <d:response>
    <d:href>/webdav/project-folder/config.json</d:href>
    <d:status>HTTP/1.1 403 Forbidden</d:status>
  </d:response>
  <d:response>
    <d:href>/webdav/project-folder/app.js</d:href>
    <d:status>HTTP/1.1 424 Failed Dependency</d:status>
  </d:response>
  <d:response>
    <d:href>/webdav/project-folder/styles.css</d:href>
    <d:status>HTTP/1.1 424 Failed Dependency</d:status>
  </d:response>
</d:multistatus>

Batch API request with dependency chain

http

POST /api/batch HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"operations": [{"id": "op1", "method": "POST", "path": "/users", "body": {"email": "[email protected]"}}, {"id": "op2", "depends_on": "op1", "method": "POST", "path": "/teams/5/members", "body": {"user_id": "$op1.id"}}]}

424 response — batch operation dependency failure

http

HTTP/1.1 200 OK
Content-Type: application/json

{"results": [{"id": "op1", "status": 422, "error": "Invalid email format"}, {"id": "op2", "status": 424, "error": "Failed dependency: op1 did not complete successfully. Cannot add user to team without valid user creation.", "failed_dependency": "op1"}]}

Deployment pipeline — dependent service fails

http

POST /api/deployments/release-42/services/payment-gateway/deploy HTTP/1.1
Host: deploy.example.com
Authorization: Bearer deploy-token

424 response — upstream dependency not deployed

http

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

{"error": "failed_dependency", "message": "Cannot deploy payment-gateway: dependency 'auth-service' failed to deploy in this release.", "failed_dependency": {"service": "auth-service", "status": "deploy_failed", "error": "Health check timeout after 60s"}, "resolution": "Fix and redeploy auth-service first, then retry this deployment."}

Edge Cases

•424 means the dependency failed — not that the dependency is missing. A missing dependency (service not found, unknown reference) is typically 400 or 404, not 424.
•Always identify WHICH dependency failed in the response body. Without this, the client has no way to know what to fix first.
•In batch operations, distinguish between hard dependencies (op2 cannot run without op1) and soft dependencies (op2 can run independently). Only hard dependency failures warrant 424.
•424 is NOT appropriate for timeout-based failures where the dependency might still succeed — use 503 or 504 for transient availability issues. 424 means the dependency definitively failed.
•Circular dependencies that result in all operations failing should not all return 424. Identify the root failure and return its actual error code; only truly dependent operations get 424.
•For deeply nested dependency chains (A→B→C→D), the response should trace back to the root cause, not just the immediate parent. Client needs to know A failed, not just that C failed because B failed.
•Some APIs use 424 for feature flag dependencies — a feature requires another feature to be enabled. This is a valid extension of the semantic but should be documented clearly.

When You'll See This

→WebDAV COPY of a folder where one file fails ACL check — dependent files get 424
→Batch API: creating a user fails validation, so adding that user to a team gets 424
→CI/CD pipeline: build step fails, so deploy step returns 424
→Database migration: migration 003 fails, so migrations 004 and 005 get 424
→Workflow engine: approval step rejected, so payment disbursement step gets 424
→Microservice orchestration: upstream service deployment fails health check, downstream services get 424
→Infrastructure provisioning: VPC creation fails, so subnet and security group creation get 424
→Transaction saga: compensation step depends on a commit that already rolled back

Implementation References

Language	Constant
Go	http.StatusFailedDependency
Rust	http::StatusCode::FAILED_DEPENDENCY
Python	http.HTTPStatus.FAILED_DEPENDENCY
Node.js	http.STATUS_CODES[424]
.NET	HttpStatusCode.FailedDependency (426 in older versions)
Java	HttpStatus.FAILED_DEPENDENCY (Spring)
PHP	Response::HTTP_FAILED_DEPENDENCY (Symfony)
Ruby	:failed_dependency (Rack)

History

Introduced in RFC 4918 (2007) as part of the WebDAV (Web Distributed Authoring and Versioning) extension to HTTP. The original use case was collection operations: when COPY or MOVE of a directory encounters a failure on one member, other members whose integrity depends on the failed member receive 424. The status code existed in the earlier RFC 2518 (1999) with the same definition. While WebDAV usage has declined, the clean semantic of 'dependency failure' led to adoption in modern REST APIs for batch operations, CI/CD pipelines, and workflow engines. It fills a gap that 409 (state conflict), 500 (unexpected error), and 503 (service unavailable) don't cover — the specific case where a prerequisite action failed, making the dependent action impossible.

Related Status Codes

207 Multi-Status 409 Conflict 423 Locked 500 Internal Server Error 503 Service Unavailable

Related Headers

If Depth

FAQ

When should I use 424 Failed Dependency vs 409 Conflict?

Use 409 when the request conflicts with the current state of the target resource — a uniqueness violation, stale version, or invalid state transition. The client can resolve the conflict and retry that specific request. Use 424 when the request itself is valid but cannot proceed because a DIFFERENT operation it depends on has failed. The client cannot fix a 424 by modifying their request — they must fix the failed dependency (a completely different operation) and retry the entire chain. 409 = 'this resource has a problem.' 424 = 'a different resource that this one needs had a problem.'

How should I structure a 424 response body for batch operations?

Include three pieces of information: (1) which dependency failed — the operation ID, resource path, or service name that was the prerequisite, (2) why it failed — the actual error from the failed dependency so the client knows the root cause without making another request, and (3) what to do — clear resolution guidance like 'fix validation errors in operation op1 and resubmit the entire batch.' For deeply nested chains (A depends on B depends on C, and C failed), trace back to the root cause rather than just reporting the immediate parent failure.

Is 424 appropriate outside of WebDAV contexts?

Yes. While 424 originated in WebDAV (RFC 4918), its semantic — 'this action failed because a prerequisite action failed' — is universally applicable. Modern REST APIs use it for batch operations with inter-item dependencies, CI/CD pipelines where build failures block deployments, saga/workflow patterns where step N depends on step N-1, and infrastructure-as-code where resource creation has ordering dependencies. The key test: is there an explicit dependency relationship where one operation's failure makes another operation impossible? If yes, 424 is appropriate. If the failure is about resource state (use 409), transient unavailability (use 503), or an unexpected error (use 500), those are better fits.

Source: RFC 4918 §11.4