Argocd Unable To Sync: Another Operation Is Already In Progress

The argocd unable to sync: another operation is already in progress error means Argo CD sees a sync or app operation already running or stuck.

If you work with GitOps for a while, you eventually bump into a sync that refuses to start. The Argo CD UI flashes a red banner, logs talk about a failed precondition, and your deployment sits there unchanged while pressure builds to ship a fix.

This guide walks through what the message means, where to look for the stuck work, and practical ways to clear it from the Argo CD UI and the cluster. It also shows how to avoid tripping the same check again when webhooks, pipelines, and humans all try to sync at once.

What This Error Means In Argo CD

Argo CD allows only one active operation per application at a time. That operation can be a sync, a rollback, a delete, or a refresh that includes hooks and other tasks. When the controller sees an operation already recorded for an app, it blocks new work for that app until the record clears.

Inside the controller, that guard returns a FailedPrecondition status over gRPC when a second operation request arrives while the first one still owns the application. The UI and CLI surface that as text along the lines of “unable to sync: another operation is already in progress”. The wording can vary slightly between versions, yet the meaning stays the same: “wait, something else is still running here”.

Operations That Count As “In Progress”

Manual Sync From The UI — A user clicks Sync on the application page or in a group view and starts a rollout.
Auto Sync Triggered By Git — A push lands on the tracked branch, Argo CD notices drift, and starts a sync on its own.
Sync Started By CLI Or API — A script, pipeline, or external job calls argocd app sync or the REST API for that app.
Rollback Or History Action — A user selects an older revision and asks Argo CD to roll back, which also counts as an operation.

If any of these stays open, the controller still treats the app as busy even if the UI view looks calm at first glance.

Common Causes Of Argocd Sync “Another Operation Already In Progress” Errors

Several patterns tend to trigger conflicts. Each leaves the app in a state where Argo CD thinks something is still happening, even if traffic already flows through the cluster as usual.

Typical Scenarios Behind The Message

Auto Sync Fighting Manual Sync — A push triggers auto sync, and a user clicks Sync at nearly the same moment for the same app.
Concurrent API Or CLI Calls — A pipeline loops over many apps and starts syncs in parallel, including several calls for the same app.
Hooks Or Jobs That Hang — PreSync or PostSync hooks, or cluster Jobs they start, never reach a healthy state so the operation never closes.
Resources Stuck Terminating — A Deployment, Namespace, or other object hangs with a finalizer that never finishes, so Argo CD waits forever.
Interrupted Operations — The controller pod restarts in the middle of a sync and leaves stale operation data behind in the Application status.

To keep these cases straight, it helps to map symptoms to likely causes. The table below gives a quick view that you can match against what you see in the UI and logs.

What You See	Likely Cause	First Check
Banner about another operation while auto sync is enabled	Auto sync already running when you click Sync	Check app history and recent Git pushes
Many 400 errors from the Argo CD API in logs	Script starts several syncs for the same app at once	Review pipeline loops and concurrency settings
Operation shows “Running” for a long time	Hook, Job, or resource health never reaches a finished state	Inspect hook pods and their logs in the cluster
Application stuck in Syncing or Terminating	Finalizer or resource deletion blocked	Look for finalizers on the Application or child resources
Error starts after controller restart or upgrade	Old operation record still stored on the Application	View Application YAML and status.operationState

Why Argocd Unable To Sync: Another Operation Is Already In Progress Appears

The text argocd unable to sync: another operation is already in progress usually comes from one of two places: the Argo CD API response when a client asks for a sync, or the controller logs when it tries to start work on the same app twice.

On the server side, the controller inspects the Application resource and checks whether an operationState exists and still counts as active. If so, it rejects new sync attempts, since editing workloads while a different change set is in flight can leave resources in a strange state. The error message might mention “unable to sync” or “unable to deploy revision”, yet both point to the same guard.

On the client side, the CLI or UI shows that text when the gRPC call returns the precondition error. So the message itself is less about Git content and more about the lifecycle of the last operation for that app.

Step By Step: Clear A Running Sync From The UI

If the operation is actually still running, the best fix is to let it finish or stop it cleanly. The Argo CD UI makes this straightforward once you know where to look.

Use The Application Details View

Open The Application Page — In the Argo CD UI, go to Applications and select the app that shows the error.
Check The Operation Panel — On the app page, open the Operation or History section and look for an entry marked as running.
Inspect Resource Status — Click through to the tree view and see which resources still show Progressing, Pending, or Terminating.
Decide To Wait Or Stop — If pods are still rolling, it can be safer to wait. If nothing moves for a long stretch, consider ending the operation.

Terminate A Stuck Operation

Use The Terminate Action — From the Operation view, use the Terminate button for the current sync. This tells Argo CD to stop tracking that rollout as active.
Watch The Status Settle — Wait until the app status flips back to Synced, OutOfSync, or Degraded rather than Syncing.
Trigger A Fresh Sync — When the app no longer shows any running operation, click Sync again or let auto sync pick up the next change.

If the UI refuses to terminate, or the status flips back to Syncing on its own, the controller might be stuck or the cluster resources might block cleanup. In that case you may need to step outside the UI.

Cluster Level Fixes When The Controller Or Resources Are Stuck

Sometimes the problem sits in the controller or in Kubernetes objects that never finish their work. In those cases, clearing the state from the cluster often releases the error.

Restart The Argo CD Application Controller

The controller drives all application operations. A glitch there can freeze operation records and keep apps busy forever. A short restart via kubectl is safe in most setups, since Argo CD rebuilds state from Applications and Git.

Roll Out A Restart — Run kubectl -n argocd rollout restart statefulset argocd-application-controller (or the matching resource in your install).
Wait For Pods To Become Ready — Use kubectl -n argocd get pods until the controller pod returns to Ready status.
Refresh The App In The UI — Open the affected app and click Refresh, then check whether the operation still shows as running.

Deal With Finalizers And Terminating Resources

If an Application or a child resource sits in a Terminating phase for a long time, Argo CD waits as the deletion never finishes. That leaves the last operation open and triggers fresh conflicts.

Inspect Finalizers On Resources — Run kubectl describe on pods, Deployments, or Namespaces that refuse to disappear and look for finalizers fields.
Review Finalizers On The Application — Check the Application resource itself for the resources-finalizer.argoproj.io entry that can block deletion in some cases.
Edit Only When You Understand The Risk — If a finalizer no longer makes sense, remove it through kubectl edit or the Manifest editor in the UI so that the resource can finish deleting.

Once the blocked resource disappears and the Application status refreshes, the previous operation usually closes and new sync requests no longer hit the same guard.

Prevent Future Argocd Sync Operation Conflicts

After you clear the immediate issue, it helps to adjust your setup so you rarely see the error again. A few small changes to version choice, automation, and hooks can cut down on conflicts a lot.

Keep Argo CD Versions Current

Several Argo CD releases have improved how auto sync and operation checks behave. In some versions, auto sync could fail with “another operation is already in progress” more often than needed. Newer releases reduce those edge cases and handle retries more gracefully.

Track Release Notes — Review the Argo CD changelog for fixes related to auto sync and operation handling, then plan upgrades on a regular schedule.
Test Upgrades In A Non-Production Cluster — Before changing production, upgrade a staging cluster and confirm that sync flows and hooks behave as expected.

Reduce Overlapping Sync Triggers

Conflicts grow when several tools attempt to drive the same app. A bit of coordination keeps Argo CD in charge without constant clashes.

Pick One Main Trigger Per App — Decide whether auto sync, webhooks, or pipelines should start syncs, and avoid stacking all of them for the same target.
Stagger Pipelines — If a pipeline must call the Argo CD API directly, add small delays or queuing so that one app does not receive many sync calls at once.
Add Simple Backoff Logic — When your script sees the error text from the API, wait a short time and try again instead of failing straight away.

Design Hooks And Jobs To Finish Cleanly

Hooks that never complete keep operations open forever. A short review of hook design can pay off in calmer syncs.

Set Reasonable Timeouts — Configure hook Jobs with timeouts or backoff limits so that they do not run forever.
Watch Hook Logs During Changes — When you add or adjust PreSync and PostSync hooks, watch their logs during the next rollout to confirm that they reach completion.
Limit Hook Scope — Keep hook tasks narrow so that a failure hits a small slice of work instead of an open-ended script that never ends.

Once you understand that the error simply protects an app from overlapping operations, it feels less mysterious. You clear the stale work, give Argo CD a clean Application state, and line up your triggers so only one sync touches a given app at a time. After that, the message argocd unable to sync: another operation is already in progress turns into a rare warning instead of a regular part of your deploy routine.