Job Support Bridge

DevOps guide

Terraform state lock errors: check ownership before retrying

Understand why a state lock exists, identify the operation that owns it, and investigate contention without bypassing the protection.

Terraform uses state locking on backends that support it to prevent concurrent operations from corrupting state. A failure to acquire a lock means you need to establish who owns the operation before attempting recovery.

1. Keep the original error and its context

Record the backend, intended environment, workspace, operation time, and relevant CI run. Inspect any lock ownership details in the message. Check whether another engineer, scheduled job, or deployment pipeline is already working with the same state.

2. Confirm the workspace and backend

terraform workspace show

Compare the selected workspace with the intended environment. Review the backend configuration and existing initialization settings. Different working directories can still point to the same remote state, so the repository directory alone does not establish ownership.

3. Allow an active operation to finish

If you identify a running operation, coordinate with its owner and let it complete. Check the CI job's real status rather than assuming a browser tab closing has stopped Terraform. Serializing operations against the same state helps avoid repeat contention.

4. Investigate interrupted operations carefully

A failed runner or interrupted command may leave a lock behind, but verify that the original process has stopped. Review run history and the backend's locking behavior with the responsible operator. Backend differences matter; there is no universal lock record to delete safely.

Keep the protection intact. Do not use disabled locking or manual lock deletion as routine troubleshooting. HashiCorp's force-unlock guidance applies to your own lock when automatic unlocking failed; uncertain ownership needs investigation first.

What to bring to a support session

A redacted error, backend type, workspace name, and CI run timeline. The goal is to establish whether contention is expected, an operation is still active, or recovery is genuinely required before changing anything.

Official references

Published 31 October 2026. Check changes against your own environment and your team’s process.