Fix: Error acquiring the state lock

This error means Terraform tried to take the state lock before making changes and could not, because something else already holds it. The lock exists so two runs cannot write the same state at once, which would corrupt it. Most of the time the holder is not a live run at all but a crashed or killed one that never released the lock, and the fix is to confirm nothing is active and then release it deliberately.

Error: Error acquiring the state lock

Error message: ConditionalCheckFailedException: The conditional request failed
Lock Info:
  ID:        9db590f5-3f6f-6c8e-1234-abcdef012345
  Path:      my-bucket/env/prod/terraform.tfstate
  Operation: OperationTypeApply
  Who:       ci-runner@build-42
  Created:   2026-07-13 14:02:11.123456 +0000 UTC

What this error means

Before a plan or apply that could change state, Terraform acquires a lock on the backend so no other run can proceed at the same time. With the S3 backend that lock is an item in a DynamoDB table identified by a LockID; with Terraform Cloud the run holds the lock. If the lock is already present, Terraform refuses to continue and prints the lock metadata: the ID, the state path, the operation, who took it, and when. That metadata is the whole point. It tells you whether the holder is a real, active run or a ghost left by one that died.

Common causes

• A previous apply was killed or crashed (CI job cancelled, network dropped, process force stopped) and never released the lock.
• Two runs are genuinely happening at once, for example a teammate applying while CI also applies, which is the lock working as designed.
• A local run and a pipeline run targeting the same state at the same time.
• The DynamoDB lock table is misconfigured or throttled, so the release write failed even though the run finished.
• A long running apply that is still in progress and simply has not finished yet.

How to fix it

Stabilize

1. Do not force anything yet. Read the lock info that Terraform printed. The Who, Created, and Operation fields tell you whether a run might still be alive. If Created is only seconds or minutes old and matches an active CI job, wait for it.

2. Confirm no run is actually holding the lock. Check your CI system for a running Terraform job, ask teammates, and look for a live process locally.

ps aux | grep terraform

Diagnose

1. For the S3 and DynamoDB backend, inspect the lock item directly so you can see it with your own eyes rather than trusting the error alone.

aws dynamodb get-item \
  --table-name my-terraform-locks \
  --key '{"LockID":{"S":"my-bucket/env/prod/terraform.tfstate"}}'

2. If the item exists but no run is active, it is a stale lock left by a crashed apply. Note the lock ID from the error output, since force-unlock needs it exactly.

Fix

Once you have confirmed nothing is running, release the lock using the exact ID from the error. Run this from the same working directory and backend configuration as the blocked run.

terraform force-unlock 9db590f5-3f6f-6c8e-1234-abcdef012345

Terraform will ask for confirmation and then remove the lock. Re run your plan or apply, and it should acquire the lock cleanly this time.

terraform plan

If you are on Terraform Cloud, do not use force-unlock blindly. Open the run in the UI, confirm it is not still applying, and use the Force cancel control on that run instead, which releases the lock as part of ending the run.

How to prevent it

• Let runs exit cleanly. Avoid killing a Terraform process mid apply; cancel through your CI so the lock is released.
• Serialize applies to the same state. Use a single pipeline or a queue so a human and CI never apply the same state at once.
• Give CI jobs generous timeouts so long applies are not killed halfway through.
• Make sure the DynamoDB lock table has enough capacity and is not throttled, so release writes always succeed.
• Keep the lock ID handy from the error output; never guess it.

When to call a senior engineer

If the lock keeps reappearing after you clear it, if you cannot tell whether a run is truly active, or if you suspect state was written by two runs at once and resources no longer match the state file, you are past a simple unlock and into state recovery. That is delicate work, since a wrong move can orphan or duplicate live infrastructure. Erzon engineers can trace what actually ran, reconcile the state file with reality, and get your pipeline moving again without breaking what is already deployed.