Check app status

"Is my app OK?" has three levels of detail, each one a bit deeper than the last. Start shallow; only go deeper when the previous level raised a flag.

Level 1 — ArgoCD status (the GitOps layer)

argocd app list

Behind Cloudflare Zero Trust?

If raw argocd commands stall or error out, use our wrapper: ./untracked/scripts/argo.sh app list. See GitOps & ArgoCD → the argo.sh wrapper for context.

Two columns matter:

• STATUS: Synced means the cluster matches what's in the git repo. OutOfSync means someone (or something) changed the cluster directly — ArgoCD will usually revert that within a minute because selfHeal is on.
• HEALTH: Healthy means the app's resources all report ready. Progressing is transient (a rollout is happening). Degraded means something's broken — pods crashloop, a Deployment can't reach replica count, etc.

Translation table

ArgoCD says	In plain English
Synced + Healthy	The app is what the repo says it should be, and it's working
Synced + Progressing	Rollout in flight, usually resolves in under a minute
Synced + Degraded	Repo looks right, but pods aren't happy — dig into pod state (level 2)
OutOfSync + Healthy	Something got changed live; ArgoCD will try to revert soon
OutOfSync + Degraded	Both broken; usually means a manifest change broke the app

For a specific app:

argocd app get <app-name>
# e.g.
argocd app get app-wecare-adveshop4-prod

The output lists every resource the app manages, with its own status. A bad resource in the middle of an otherwise-good app is exactly where to look.

Level 2 — Pod state (the Kubernetes layer)

If ArgoCD says Degraded, drop to pod level:

# List all pods in a namespace
kubectl -n ecommercen-clients-wecare get pods

# Wide view with IPs + node names
kubectl -n ecommercen-clients-wecare get pods -o wide

# A single pod's description (the "why" column)
kubectl -n ecommercen-clients-wecare describe pod <pod-name>

What to look for in get pods:

READY	STATUS	What it means
4/4	Running	Healthy — all 4 containers in the pod are ready
3/4	Running	One container isn't ready. Describe the pod and scroll to "Last State"
0/4	CrashLoopBackOff	Pod keeps failing. Grab logs (see below)
0/4	ContainerCreating	Brand new pod, still pulling images or mounting volumes
0/4	Pending	Can't be scheduled. Describe and look at "Events" at the bottom

Level 3 — Logs (why is it doing that?)

Once you know which pod and container:

# All logs from a pod (if one container)
kubectl -n ecommercen-clients-wecare logs <pod-name>

# Specific container in a multi-container pod
kubectl -n ecommercen-clients-wecare logs <pod-name> -c <container-name>

# Last 100 lines only
kubectl -n ecommercen-clients-wecare logs <pod-name> --tail=100

# Follow live (Ctrl-C to stop)
kubectl -n ecommercen-clients-wecare logs -f <pod-name>

# Previous container instance (useful when current one is crashing)
kubectl -n ecommercen-clients-wecare logs <pod-name> --previous

For structured log exploration across all pods/services, use Loki in Grafana — Grafana → Explore → pick Loki as the datasource → query like {namespace="ecommercen-clients-wecare"}.

Common "why is it Degraded" patterns

Symptom	Most likely cause
Pod in ImagePullBackOff	Wrong image tag in the manifest, or regcred secret missing/expired
Pod in CreateContainerConfigError	Referenced ConfigMap or Secret doesn't exist yet
Pod in CrashLoopBackOff with exit code 1	App-level error; read the logs
Pod in CrashLoopBackOff with exit code 137	OOMKilled — pod exceeded its memory limit
Pod stuck Pending	Scheduler can't find a node that matches the pod's requirements (taints, resources, affinity)
Pod Ready: 0/N but Status: Running	A liveness/readiness probe is failing. Describe to see which

Good to know

• ArgoCD web UI at argocd.ecnv4-mgmt.ecommercen.com does all of Level 1 with clicks. Sign in with Google.
• Grafana Operations dashboards render a lot of this visually; see Daily checks.
• When in doubt, ask the k8s-manager agent via Claude — it runs these checks for you and explains the output.