HTTP 423 Locked — What It Means & How to Debug

HTTP 423 Locked is an HTTP response status code that indicates the requested resource is locked and cannot be accessed or modified. It originates from WebDAV (Web Distributed Authoring and Versioning) and is used to prevent concurrent edits and conflicting modifications.

What It Means

Defined in RFC 4918 Section 11.3, the 423 status code signals that the resource is currently locked by another client. WebDAV uses a locking mechanism where a client can acquire a write lock on a resource, preventing other clients from modifying it until the lock is released.

The response should include a Lock-Token header or body information identifying the lock owner or the time remaining before the lock expires.

When It’s Sent

• WebDAV concurrent editing — Two users try to edit the same document on a WebDAV-enabled server.
• CMS content locking — A content management system locks a page while an editor is working on it.
• Database row locking exposed via API — An API endpoint that reflects database-level locks.
• Collaborative document editing — Real-time collaborative tools that lock sections during editing.
• Distributed lock managers — APIs backed by distributed lock services like Redis Redlock or ZooKeeper.

Real Example

The following curl command attempts to modify a locked resource:

curl -X MKCOL https://httpbin.org/status/423 \
  -H "Content-Type: application/json" \
  -d '{"title": "Updated Title"}' \
  -v 2>&1 | grep -E "< HTTP|locked"

Expected response:

HTTP/1.1 423 LOCKED
Date: Sat, 20 Jun 2026 12:00:00 GMT
Content-Type: application/json
Content-Length: 112

{
  "error": "Locked",
  "message": "The resource is locked by another user. Lock expires in 4 minutes.",
  "lock_token": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
}

How to Debug & Fix

Client-Side

1. Wait and retry — If the lock is temporary, wait for the lock duration and retry the request.
2. Check the lock token — If your client holds the lock, include the Lock-Token header to identify yourself as the lock owner.
3. Contact the lock owner — For collaborative systems, contact the person holding the lock.
4. Force unlock — Some systems allow administrators to break locks manually.
5. Handle gracefully in code — Treat 423 as a retryable error with exponential backoff.

Server-Side

1. Set reasonable lock timeouts — Locks should expire automatically after a reasonable period (5–15 minutes).
2. Provide lock information — Return who holds the lock and when it expires in the response.
3. Implement lock discovery — Allow clients to query which resources are locked and by whom.
4. Provide an unlock mechanism — Allow administrators to break stale locks.
5. Use optimistic locking — Consider using ETags and 412 Precondition Failed instead of 423 for REST APIs.

Common Causes Table

FAQ

Related Codes

HTTP 409 Conflict — The request conflicts with the current state of the resource.

HTTP 412 Precondition Failed — A precondition header check failed (used in optimistic locking with ETags).

HTTP 422 Unprocessable Entity — The server understood the request but cannot process it.

HTTP 429 Too Many Requests — The client has sent too many requests in a given time.