423 - Locked
HTTP 423 Locked means the source or destination resource is locked and cannot be modified yet.
Last reviewed: February 4, 2026|Editorial standard: source-backed technical guidance
What Does Locked Mean?
A lock on the target resource is actively preventing modification, so writes must wait for release or provide valid lock context.
Common Causes
- -WebDAV lock token is missing from If header while another editor holds an active resource lock.
- -Distributed mutex entry remains held after worker crash because lock TTL and heartbeat are misconfigured.
- -Workflow state marks document immutable during approval stage, and write operations are blocked by policy.
How to Fix Locked
- 1Identify active lock owner and lock token requirements for the target resource.
- 2Release, refresh, or transfer lock safely before retrying the blocked mutation.
- 3Include required lock token/context in mutation request where lock-aware APIs demand it.
Step-by-Step Diagnosis for Locked
- 1Capture lock metadata (owner, token, timeout, scope) returned with 423 response.
- 2Inspect lock service/store for stale, orphaned, or expired locks not cleaned correctly.
- 3Trace workflow paths that acquire locks and verify release logic on success and failure.
- 4Retest mutation with valid lock token after lock lifecycle is corrected.
Lock Ownership and Token Validation
- -Confirm lock token identity and scope (example: write attempt uses token for parent resource, but child resource lock is separate).
- -Check lock timeout/refresh behavior (example: token expired but lock entry remained due cleanup failure).
Workflow Lock Lifecycle and Release Guarantees
- -Audit lock release in failure paths (example: exception skips unlock call and leaves orphaned lock).
- -Inspect concurrent actor behavior (example: background job holds lock beyond SLA during long-running operation).
Implementation Examples
curl -i -X POST https://api.example.com/v1/resource -H "Content-Type: application/json" -d "{"sample":true}"
# Response:
# HTTP/1.1 423 Locked
# {"error":"Locked","code":"423"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'Accept': 'application/json' },
body: JSON.stringify({ sample: true })
});
if (response.status === 423) {
console.error('Handle 423 Locked');
}import requests
response = requests.post(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json', 'Content-Type': 'application/json'},
json={'sample': True}
)
if response.status_code == 423:
print('Handle 423 Locked')How to Verify the Fix
- -Repeat blocked mutations and confirm 423 clears when valid lock ownership/token is provided.
- -Validate lock acquire/refresh/release lifecycle under concurrent and failure scenarios.
- -Monitor lock contention and stale-lock metrics for sustained improvement.
How to Prevent Recurrence
- -Define strict lock TTL, heartbeat, and stale-lock cleanup policies.
- -Enforce lock release in finally/defer blocks across all mutation handlers.
- -Monitor lock contention, stale token, and orphaned lock signals with alerts.
Pro Tip
- -attach owner identity and acquisition stack metadata to lock records so orphaned-lock triage can be resolved in minutes, not hours.
Decision Support
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
404 Not Found vs 410 Gone: Missing vs Permanent Removal
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.
Playbook
Resource State Playbook (404 / 410 / ResourceNotFound)
Use this playbook to separate temporary missing-resource lookups from permanent removals, then fix scope, lifecycle, and identifier drift safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.