423 Locked 4xx

What does 423 mean?

A 423 Locked response means the resource being accessed has a lock on it, preventing the requested operation. Like 422, this code originated in WebDAV (RFC 4918) — a protocol extension for collaborative document editing — where explicit resource locking was a core feature: a user could "lock" a document while editing it, preventing others from making conflicting changes simultaneously.

423 communicates "this isn't necessarily about your permissions or the request's validity — this specific resource has an active lock on it right now, placed by someone or something, and that lock is blocking this operation."

How a 423 behaves

• It can carry a body explaining the lock — potentially including who holds it, or when it might be released
• It's not cacheable — lock status is dynamic and can change
• It's distinct from 409 — while both relate to "current state" conflicts, 423 specifically indicates an explicit lock mechanism (a deliberate, often time-limited hold on the resource), whereas 409 covers a broader range of state conflicts that don't necessarily involve a formal locking system
• Locks are often temporary by nature — unlike a 403 (which implies a persistent permission issue) or 410 (permanent removal), a 423 often resolves itself once the lock is released

Common causes

If you're building the API or website:

• Your application implements an explicit locking mechanism (e.g., "this document is being edited by another user" in a collaborative editing tool) and is correctly preventing concurrent modifications
• A background process has placed a temporary lock on a resource while performing some operation (e.g., a data migration, an export job) that shouldn't be interrupted by concurrent edits

If you're calling an API:

• You're trying to modify a resource that another user/process currently has locked for editing
• A previous operation placed a lock that wasn't released properly (e.g., due to a crash), leaving the resource in a locked state longer than intended

If you're a website visitor:

• You're trying to edit a document, record, or file that someone else currently has open for editing in a collaborative tool
• A resource you're trying to modify is temporarily locked due to an in-progress operation (an export, an import, a sync process)

How to fix it

As an API/website builder:

• Implement lock timeouts/expiration so that locks can't persist indefinitely if a process crashes or a user closes their browser without releasing a lock
• Provide clear information to users about why something is locked and, if possible, who holds the lock or when it might be released
• Consider whether a "request to be notified when unlocked" or similar UX pattern would help users dealing with locked resources

As an API consumer:

• Wait and retry — locks are often temporary, and the resource may become available shortly
• If implementing your own locking logic, ensure locks are released reliably (including in error/crash scenarios) to avoid resources becoming permanently stuck in a locked state

As a website visitor:

• Wait a bit and try again — someone else may currently be editing the resource, and the lock should release when they finish
• If a resource seems permanently locked (and you believe this is an error), this typically requires the site/application's support or an administrator to manually clear the stuck lock

423 vs 409 vs 424

Real-world examples

Collaborative document editing systems (in the spirit of WebDAV's original use case) implement locking to prevent two users from making conflicting edits to the same file simultaneously — 423 is the standardized HTTP-level signal for "this is currently locked by someone else's edit session." Some content management systems implement editorial locking — when one editor opens a page/article for editing, the system locks it, returning 423 (or an application-level equivalent) if another editor tries to open the same content simultaneously.

SEO implications

423 is exclusively relevant to write operations on resources with explicit locking mechanisms (typically collaborative editing/CMS contexts) and has no bearing on page-level SEO or content delivery to search engines.

FAQ

What's the difference between 423 and 409?

423 specifically indicates an explicit lock on the resource — a deliberate, often temporary hold preventing modifications. 409 is a broader "conflicts with current state" response that doesn't necessarily involve any formal locking mechanism.

Are 423 locks always temporary?

Typically, yes — locks are usually associated with an active editing session, an in-progress operation, or a time-limited hold. However, if a lock isn't released properly (due to a bug, crash, or missing timeout logic), a resource could remain locked longer than intended, requiring manual intervention to clear.

Does 423 mean I don't have permission to edit this resource?

Not necessarily — 423 is about the resource's current locked state, independent of your permissions. You might have full permission to edit the resource, but it's currently locked by someone/something else's active session.

How do applications typically release locks?

Through explicit "unlock" actions (a user finishes editing and saves/closes), automatic timeouts (locks expire after a period of inactivity), or cleanup processes that detect and release stale locks from crashed sessions.

Is 423 common outside of collaborative editing tools?

It's most associated with its WebDAV origins (collaborative document editing) and similar locking-based systems. Many modern APIs handle concurrent-modification concerns via optimistic concurrency (409/412 with ETags) rather than explicit locking (423), making 423 less common than these alternatives in typical REST API design.

Fun fact

423, alongside 422 and 424, forms a small group of status codes that all trace back to WebDAV's relatively ambitious (for its time) vision of HTTP as a protocol for collaborative document management — complete with locking, dependency tracking, and detailed validation semantics — features that, while niche in WebDAV's specific original context, established conceptual vocabulary ("locked," "failed dependency," "unprocessable") that later proved useful well beyond document editing.