HTTP 423 Locked Status Code Explained for Website Owners

The 423 Locked status code is a 4xx client error that indicates a requested resource is currently locked and cannot be accessed or modified. It’s part of the WebDAV (Web Distributed Authoring and Versioning) protocol extension to HTTP, designed to prevent conflicting modifications when multiple users or processes access the same file or folder. Unlike common errors like 404 (Not Found) or 500 (Server Error), 423 specifically means the resource exists but is temporarily unavailable due to an active lock.

The lock is intentional rather than accidental. It’s a protective mechanism to maintain data integrity during editing, backups or administrative tasks. Think of it like a “Do Not Disturb” sign on a hotel room door: the room exists and will be available later, but right now it’s occupied and you need to wait. Whilst 423 is a standard HTTP status code defined in RFC 4918, it’s relatively rare outside WebDAV-enabled environments. Most website owners will only encounter it when using specific file management features or collaborative editing tools that rely on WebDAV protocols to coordinate access between multiple users or automated processes.

Understanding what causes 423 errors helps you identify whether you’re experiencing a normal occurrence or a problem requiring action. The triggers span several distinct scenarios, from everyday collaborative work to server maintenance and technical misconfigurations. Recognising these patterns allows you to respond appropriately rather than treating every 423 error as an emergency.

When multiple users attempt to edit the same document, page or file simultaneously in a collaborative CMS or WebDAV-enabled system, the first user to open the resource typically locks it. Subsequent users receive a 423 error until the first user saves and closes. This is common in content management systems with collaborative features, shared document editing or team environments where several people manage website content. For example, if two team members try to edit the same WordPress page via WebDAV simultaneously, the second person will encounter a 423 response until the first completes their changes and releases the lock.

Automated backup systems, server maintenance tasks or file synchronisation processes often lock files or directories temporarily to ensure data consistency. During these operations, attempts to modify affected resources return a 423 error. This typically lasts seconds to minutes depending on backup size and usually resolves automatically once the process completes. These locks are more common on VPS or dedicated servers where you manage backups yourself, though shared hosting providers also run scheduled backups that may briefly lock your files.

Version control systems like Git when accessed via WebDAV or cloud synchronisation tools may lock files during commit, push or sync operations. This prevents conflicting changes from corrupting the repository. If you’re deploying website updates via version control, you might encounter 423 errors during the deployment window. Developers working with continuous integration pipelines occasionally see these locks when automated deployments coincide with manual file edits, creating temporary access conflicts that resolve once the deployment completes.

Administrators can manually lock files or directories for security reasons, such as protecting critical configuration files, preventing changes during troubleshooting or securing a site during a security incident. These locks persist until manually removed. Less common than automatic locks, administrative locks are intentional rather than errors. You’ll typically encounter them when your hosting provider or system administrator needs to prevent modifications whilst investigating issues or implementing security fixes. Recognising these as deliberate actions helps you understand that contacting support for an unlock is the appropriate response.

Incorrect WebDAV configuration, file permission issues or stale lock files (locks that weren’t properly released after a process crashed) can cause persistent 423 errors. This is a genuine problem requiring technical investigation, unlike temporary locks which resolve naturally. Stale locks occur when a process that created a lock terminates unexpectedly without cleaning up, leaving the lock file orphaned on the server. This scenario is more likely on self-managed VPS or dedicated servers where configuration errors can accumulate. Checking server logs for error messages helps identify whether you’re dealing with a misconfiguration or simply waiting for a legitimate lock to expire.

Understanding how 423 errors impact both user experience and search visibility helps you prioritise fixes and prevent long-term damage to your site’s performance and rankings.

Users encountering a 423 error cannot access or modify the locked resource, which disrupts workflows in collaborative environments or prevents file uploads and edits. For public-facing website visitors, a 423 error on a page or resource means they see an error message instead of content. Whilst temporary locks lasting seconds to minutes have minimal impact, persistent 423 errors frustrate users and may drive them away. Most browsers display 423 as a generic error page unless the server provides a custom error message, so visitors often don’t understand why they can’t access the content. This creates confusion and reduces trust in your site’s reliability, particularly if the error recurs frequently or affects critical pages like checkout processes or contact forms.

Search engines like Google treat 423 as a client error indicating temporary unavailability. If a URL consistently returns 423, Google may eventually deindex it (remove it from search results) because the content appears permanently inaccessible. This is similar to how Google handles other 4xx errors. Short-lived 423 errors during maintenance are unlikely to cause deindexing, but persistent 423 responses over days or weeks will harm your search visibility. The 423 response should ideally include a Retry-After header telling search engines when to check back, though this is often missing in practice.

If you’re performing planned maintenance that locks resources, use a 503 Service Unavailable status instead, which explicitly signals temporary unavailability to search engines. This prevents Google from treating the issue as a permanent problem and protects your rankings during scheduled downtime. Monitoring your Google Search Console for 4xx errors helps you catch persistent 423 responses before they cause significant ranking drops.

Knowing what happens when a server returns a 423 error helps you troubleshoot more effectively and communicate clearly with developers or hosting support. The technical structure of these responses follows specific standards that determine how clients and servers handle locked resources.

A 423 response includes a status line (HTTP/1.1 423 Locked), response headers and typically an XML body following WebDAV standards that describes the lock. The XML body explains why the resource is locked and may include lock token information. This structure provides both machine-readable information for automated systems and human-readable context for troubleshooting. The key elements are the status code itself, headers like Lock-Token and Content-Type, and an XML error description that specifies which resource is locked and why.

Key headers that may accompany a 423 response include:

• Lock-Token: Identifies the specific lock preventing access. You must provide this token in an If header to prove you have permission to remove the lock.
• Retry-After: Suggests when to retry in seconds (e.g., Retry-After: 120 means wait two minutes).
• Content-Type: Usually application/xml for WebDAV error bodies containing detailed lock information.

The Retry-After header is particularly valuable for automated systems, allowing them to schedule retries intelligently rather than hammering the server with repeated failed requests. If you’re working with WebDAV APIs, storing the Lock-Token when you lock a resource allows you to unlock it later. Without this token, you’ll need administrative access to remove the lock manually.

WebDAV defines two lock types: exclusive locks (only one user can modify) and shared locks (multiple users can read, but modifications are coordinated). Locks can be scoped to a single resource or an entire directory tree. They have timeouts typically ranging from minutes to hours and should automatically expire. Stale locks can persist if a client crashes without unlocking. Understanding whether a lock is functioning as intended or has become orphaned helps you determine if manual intervention is needed.

When you encounter a 423 error, following a systematic diagnostic process helps you identify the cause quickly and determine the appropriate fix. Start by checking browser developer tools (Network tab) to confirm the 423 status code and examine response headers. Look for Lock-Token, Retry-After or error messages in the response body that provide clues about the lock’s origin and expected duration.

Determine if the error is temporary or persistent by waiting a few minutes and retrying. If it persists, investigate further. Check if you or a colleague are currently editing the resource in question, which is common in collaborative CMSs. Review recent server activity by checking your hosting control panel or server logs to see if backups or maintenance tasks were running when the error occurred.

Test with different files or URLs. If only one resource returns 423, it’s likely a specific lock on that file. If multiple resources are affected, suspect a server-wide issue or misconfiguration. Look for stale lock files on the server (usually in a .locks or similar directory if using WebDAV), which may need manual removal. If you’re on shared hosting, contact your provider as you likely don’t have access to diagnose server-level issues yourself. Shared hosting customers should escalate persistent 423 errors to technical support rather than attempting server-level troubleshooting, as the necessary access and tools aren’t typically available in shared environments.

Resolving 423 errors requires different approaches depending on whether you’re dealing with an immediate problem or trying to prevent future occurrences. The solutions range from simple waiting to technical server configuration, with your hosting environment determining which options are available to you.

When facing an active 423 error, try these steps in order:

1. Wait and retry. Most locks are temporary (seconds to minutes). Check for a Retry-After header indicating when to try again.
2. Check for active editing sessions. If you or a colleague are editing the resource, save and close to release the lock.
3. Use the lock token if you have it. If you locked the resource programmatically, send an UNLOCK request with the Lock-Token in the If header.
4. Restart relevant processes. If a backup or sync process appears stuck, restarting it may release the lock (requires server access).
5. Manually remove stale lock files. If you have server access and identify stale .lock files, delete them with caution. Only delete lock files if you’re certain the process that created them has finished or crashed.
6. Contact your hosting provider. If you’re on shared hosting or can’t resolve the issue, ask support to investigate and unlock the resource.

The majority of 423 errors resolve through the first two steps. Escalate to technical intervention only when simple solutions fail and the error persists beyond reasonable timeframes.

Preventative strategies reduce the frequency and impact of 423 errors:

1. Coordinate editing in teams. Use your CMS’s built-in collaboration features or communicate before editing shared resources.
2. Schedule maintenance during low-traffic periods. If backups or updates lock resources, run them when users are least likely to be affected.
3. Configure lock timeouts appropriately. If you manage your own server, set reasonable WebDAV lock timeouts (e.g., 10-30 minutes) to balance protection against stale locks.
4. Implement proper error handling in applications. If you’re developing against WebDAV APIs, handle 423 responses gracefully with retry logic and user-friendly messages.
5. Monitor for persistent locks. Regularly check server logs or use monitoring tools to identify resources that remain locked longer than expected.
6. Use version control workflows. Instead of direct WebDAV editing, consider deploying changes via Git or similar systems that handle conflicts more elegantly.

These measures work best when combined. For example, coordinating team edits whilst also implementing appropriate lock timeouts creates multiple layers of protection against problematic locks.

WebDAV support and lock behaviour depend on your hosting environment. Shared hosting typically doesn’t expose WebDAV configuration, so contact your provider if you need changes. VPS and dedicated server users can configure WebDAV modules (e.g., mod_dav on Apache, WebDAV modules on Nginx) including lock timeouts, lock database location and permissions. Some hosting control panels like Plesk or cPanel offer WebDAV management interfaces that simplify these adjustments.

If you frequently encounter 423 errors due to server configuration, your hosting setup may not suit your workflow. Consider managed hosting or a provider with better WebDAV support. Many modern hosting environments avoid WebDAV in favour of SFTP, Git or API-based file management, which handle concurrent access differently and may reduce 423 occurrences. UK VPS providers like DigitalOcean or Linode give you full control over WebDAV configuration, whilst shared hosting from providers like 123 Reg or Hostinger typically handles this automatically with limited user customisation.

Whilst most 423 errors are benign and temporary, certain patterns indicate serious problems requiring urgent attention. Recognising these warning signs helps you escalate appropriately and prevent long-term damage to your site’s accessibility and search rankings.

Watch for these critical scenarios:

1. Persistent 423 on public-facing pages or critical resources lasting hours or days. This harms SEO and user access.
2. Multiple resources locked simultaneously without obvious cause (no maintenance, backups or editing activity). This may indicate a server malfunction or security issue.
3. Locks that cannot be removed even with correct lock tokens or administrative access. This suggests file system corruption or server misconfiguration.
4. Recurring 423 errors after supposed fixes. This indicates an underlying problem such as a buggy application, misconfigured backup system or insufficient server resources causing processes to crash and leave stale locks.
5. 423 errors accompanied by other server errors (500s, slow response times). This may signal broader server health issues beyond simple locking problems.

These scenarios require technical investigation. Check server logs for errors, review resource usage (CPU, RAM, disk I/O), test file system integrity and consider whether your hosting environment is adequate for your needs. If you’re on shared hosting and see persistent unexplained 423 errors, escalate to your provider’s technical support immediately. The issue may affect other users on the same server, making it a priority for the hosting team to resolve quickly.

Understanding how 423 differs from similar error codes helps you diagnose issues correctly and apply appropriate fixes. Several 4xx errors can appear superficially similar but require completely different responses.

403 Forbidden means you lack permission to access the resource. It’s a permanent access denial based on credentials or IP restrictions, not a temporary lock. Fixing 403 requires checking permissions or authentication settings rather than waiting for a lock to expire.

409 Conflict indicates your request conflicts with the current state of the resource, but it’s not locked. This often appears for version conflicts in APIs where your update is based on outdated data. The solution involves fetching the latest version and reapplying your changes, not unlocking anything.

412 Precondition Failed means a conditional request header like If-Match wasn’t met. This relates to caching or versioning mechanisms rather than locking. You’ll see this when your request includes conditions that the current resource state doesn’t satisfy.

503 Service Unavailable indicates the entire server or service is temporarily down, not just one locked resource. This is a server-wide issue affecting all requests, whilst 423 is resource-specific.

423 is unique in indicating that the specific resource exists, you have permission to access it normally, but it’s currently locked by another process or user. Understanding these distinctions helps diagnose issues correctly. For example, a 403 requires checking permissions, whilst a 423 requires waiting or unlocking. In practice, many servers and applications don’t implement 423 correctly and may return generic 400 or 500 errors instead, making diagnosis harder and requiring you to examine response bodies and server logs for the true cause.

For technical readers, developers and agencies building or maintaining WebDAV-enabled applications or APIs, proper implementation and handling of 423 responses ensures smooth operation and good user experience. These considerations apply whether you’re building the server side that returns 423 errors or the client side that handles them.

When a resource is locked via WebDAV LOCK method or application-level locking, return HTTP/1.1 423 Locked with appropriate headers (Lock-Token, Retry-After if known) and an XML body describing the lock following RFC 4918 WebDAV error format. The response should be specific, returning 423 only for the locked resource, not for unrelated requests. Include a human-readable message in the response body for debugging purposes. Your implementation should specify the status code, set Content-Type to application/xml, include the Lock-Token header identifying the lock and optionally provide a Retry-After value in seconds.

Client applications encountering 423 should treat it as a temporary condition, not a permanent error. Check for a Retry-After header and wait the specified duration before retrying. If absent, implement exponential backoff (e.g., retry after 5 seconds, then 10, then 30). Inform the user clearly with messages like “This file is currently being edited by another user. Retrying in 10 seconds…” rather than generic errors. Store lock tokens if you create locks so you can unlock resources later. Implement timeout logic so that if retries fail after a reasonable period (e.g., 5 minutes), you alert the user and suggest manual intervention.

Developers managing locks should follow these guidelines:

1. Always set lock timeouts. Never create indefinite locks. Typical range is 5-30 minutes depending on use case.
2. Release locks explicitly. Don’t rely solely on timeouts. Send UNLOCK requests when editing is complete.
3. Handle client crashes gracefully. Implement server-side logic to detect stale locks (e.g., locks older than timeout threshold) and clean them up.
4. Use appropriate lock scope. Lock only what’s necessary (single file vs entire directory).
5. Provide lock visibility. Let users see who has locked a resource and when the lock expires.
6. Consider alternatives to WebDAV locking. For modern applications, optimistic concurrency control (using ETags or version numbers) may be simpler and more robust than explicit locks.

Following these practices prevents the majority of problematic 423 errors users encounter in production environments.

Proactive monitoring catches 423 issues before they impact SEO or user experience significantly and helps identify whether errors are isolated incidents or systemic problems requiring infrastructure changes. Website administrators and technical teams managing live sites need systematic approaches to detect and respond to 423 errors.

Enable server access logging (most web servers log HTTP status codes) and regularly review logs for 423 responses. Use uptime monitoring services like Pingdom, UptimeRobot or StatusCake to alert you if critical URLs return 423 instead of 200. Configure alerts for 4xx errors, setting thresholds such as “Alert if more than 5 423 errors occur in an hour”, which indicates a potential systemic issue rather than isolated incidents.

Integrate with Google Search Console and check the Coverage report for URLs that Google couldn’t index due to 4xx errors. 423 will appear here if affecting public pages. Implement application-level logging if you’re running custom WebDAV or collaborative applications. Log lock creation, duration and release to identify patterns such as locks frequently timing out or specific users creating many locks.

Set up automated cleanup by creating cron jobs or scheduled tasks to identify and remove stale lock files older than a threshold (e.g., 1 hour). Monitor server resources as well, since high CPU, RAM or disk I/O can cause processes to hang and leave locks unreleased. This multi-layered monitoring approach provides early warning of problems and helps you distinguish between normal operational locks and indicators of underlying infrastructure issues.

The HTTP 423 Locked status code is a specialised error indicating a resource is temporarily locked, most commonly encountered in WebDAV-enabled environments, collaborative editing systems or during server maintenance and backup operations. Whilst 423 errors are relatively rare for typical website visitors, they become significant for teams managing content collaboratively, developers working with WebDAV APIs or site owners whose resources are locked during administrative tasks.

Short-lived 423 errors lasting seconds to minutes are generally harmless and resolve naturally, but persistent 423 responses can harm SEO by causing search engines to deindex affected URLs and frustrate users who cannot access locked resources. Diagnosing 423 errors involves checking for active editing sessions, reviewing server maintenance schedules, examining lock tokens and headers, and distinguishing between temporary locks and problematic stale locks or misconfigurations. Fixes range from simply waiting and retrying to coordinating team workflows, configuring appropriate lock timeouts on your server or contacting your hosting provider for assistance, particularly if you’re on shared hosting with limited server access.

For developers, implementing 423 responses correctly with proper headers and retry logic, and managing locks responsibly with timeouts and explicit unlocking, ensures smooth operation and good user experience. Understanding 423 errors helps you maintain site accessibility, protect your search rankings and choose hosting environments suited to your collaborative or administrative workflows. If you’re evaluating hosting providers and need advice on WebDAV support, server management capabilities or alternatives that avoid lock-related issues, our free guidance can help you select the right web hosting solution for your specific needs.