Deployment Stuck and Never Reaches Synced or Deployed

If a deployment in SVIEW starts but never finishes, stays pending on
Synced or Deployed, shows Sync Failed, or a Workflow never moves
past New, this page tells you what to check yourself and when to hand it
to us.

Symptoms

Any of these, usually right after you saved a change, updated a variable, or
your pipeline pushed a new image:

• The change stays pending on Synced or Deployed and never completes.
• The deployment appears to sync in a loop, or keeps running an old image.
• The Component shows Sync Failed, even though its pods are running.
• A Workflow stays in New with its progress stuck at 0/1.
• The sync error contains spec.selector: Invalid value: ...: field is immutable.

How a change reaches your cluster

Every save in SVIEW moves through the same stages, in order:

1. Changed — SVIEW has accepted your edit.
2. Committed — the change has been recorded as the new desired state.
3. Synced — ArgoCD has applied the desired state to your cluster.
4. Deployed — the workload is running with the new configuration.

You see these four stages in two places. On the Component's own page they
appear as a progress bar at the top, just below its metadata, and not on a
separate tab. Each completed stage shows a short message and a timestamp
underneath, such as sync in progress, sync failed, deployment in progress or deployment degraded. Hover over a failed stage to see the error
detail. In the Applications → Deployments list, the Status column shows the same
stages as small icons; hover over an icon to see which stage it is.

The stage where it stops tells you where the problem is. A normal change goes
from Changed to Deployed within a few minutes.

Fix

Work through these in order. Most stuck deployments are resolved by the first
three.

1. Confirm the change was actually saved. Open the Component and go to the
   Versions tab. If your change is not listed as the newest version, it
   never left SVIEW: an edit that is typed and previewed but not submitted
   leaves no trace and produces no error. Make the change again and click
   Save.
2. Check what the latest change contains. Open the newest version in the
   Versions tab and read its diff. A malformed value, a misspelled variable
   name, or a variable that points at something that does not exist (a file
   path, a secret, a parameter) is the most common reason a deployment will not
   sync or will not start. See
   Configuration Versions and Rollback.
3. Roll back to the last version that worked. If you cannot see the problem
   quickly, open the last known-good version and click Rollback. That
   redeploys the previous configuration and unblocks the Component while you
   fix the change separately.
4. If it shows Synced but the application is not healthy, the delivery
   worked and the application itself is failing. Check the Component's
   Logs tab, then see
   Pod Keeps Restarting (CrashLoopBackOff) or
   Pod Killed with OOMKilled.
5. If it shows Sync Failed but your pods are running the new version, the
   status is likely left over from an earlier failed attempt. A failed sync is
   not retried automatically, so the failure stays visible after its cause is
   gone. Saving your next change starts a new sync and clears it. If you need
   the status cleared now, raise a request.
6. If your pipeline reports an authentication error, such as
   Token revoked or Forbidden, the deployment never reached SVIEW. See
   Troubleshooting Common Issues for the token
   fix.

If you have read-only ArgoCD access, the application's sync status and its
error message are also visible there. Refresh in ArgoCD re-reads the
desired state but does not start a sync. Make changes through SVIEW, not
ArgoCD.

When to raise a request

These cases need CTO2B, because the fix is on the platform side:

A blocked production deployment with no workaround is a Sev-2; see
SLA Policy for severity levels. If
production is fully down, follow
How to Raise a Sev-1 Incident instead.

Still having issues?

Raise a request in your dedicated Slack channel with:

• the Environment, Service and Component name
• the stage the change stopped at (Changed, Committed, Synced or
  Deployed) and how long it has been there
• the exact error message, if one is shown
• what you changed just before it got stuck, and when the last successful
  deployment was
• whether other Components are affected

See Getting Help for the other ways to reach us.

Related articles

• Configuration Versions and Rollback — review a change and roll it back
• Components and Deployments — how saving a change deploys it
• Workflows — multi-step operations in SVIEW
• Troubleshooting Common Issues — pipeline token and image pull errors
• SLA Policy — severity levels and response times