Configure Argo CD worker health

Configure an existing Argo CD installation to recognize Bridge’s session and proxy workers. Argo CD remains optional. It manages the same Kubernetes deployment you can install with Helm or manifests.

Bridge workers use restartPolicy: Never because the orchestrator replaces them when they finish. Argo CD v3.5.2 reports running Pods with that policy as Progressing, even when they are ready. The health check below reports ready Bridge workers as Healthy and preserves completion checks for ordinary finite Pods and hooks.

Before you begin

You need:

Bridge image v2.3.0 with chart 2.1.0, or the matching Kubernetes manifest, for worker readiness, startup, and liveness probes.
An existing Argo CD installation and permission to configure it.
kubectl, curl, and jq for the commands below.

The supplied check was verified against Argo CD v3.5.2. Review its behavior before using it with another Argo version. The check applies to all Pods managed by this Argo instance. If your installation already defines a Pod health check, merge the Bridge rules into that check before applying the configuration.

Configure the Argo instance

Download the versioned health check

Download pod-health.lua for Bridge v2.3.0. Keep this file with your Argo configuration in Git.

terminal

curl --fail --location \
  https://learn.britive.com/bridge-files/argocd/v2.3.0/pod-health.lua \
  --output pod-health.lua

Generate the ConfigMap patch

Annotation-based tracking keeps Bridge’s runtime worker labels from identifying them as Git-managed resources to prune. This setting affects resource tracking for the Argo instance. Include it in your instance’s configuration rollout. The Lua standard libraries must be enabled because the check uses string.match.

terminal

jq -n --rawfile health pod-health.lua \
  '{data: {"application.resourceTrackingMethod": "annotation",
           "resource.customizations.useOpenLibs.Pod": "true",
           "resource.customizations.health.Pod": $health}}' \
  > bridge-argocd-health.json

Apply the configuration through its owner

For an Argo instance you manage directly, apply the patch. Replace argocd if your Argo installation uses another namespace.

terminal

kubectl -n argocd patch configmap argocd-cm --type merge \
  --patch-file bridge-argocd-health.json

If Helm or Git manages argocd-cm, save the equivalent configuration there so the next deployment retains it. For the Argo Helm chart, generate a values file from the patch and merge it with your existing values:

terminal

jq '{configs: {cm: .data}}' bridge-argocd-health.json > bridge-argocd-values.json

These are values for the Argo CD chart. The Bridge chart does not configure Argo CD. Run your existing Argo release workflow with the merged values.

Verify

Check the instance settings:

terminal

kubectl -n argocd get configmap argocd-cm -o json | jq '.data | {
  tracking: .["application.resourceTrackingMethod"],
  luaLibraries: .["resource.customizations.useOpenLibs.Pod"]
}'

Expect tracking to be annotation and luaLibraries to be true as a string. Check Kubernetes worker readiness in the Bridge namespace:

terminal

kubectl -n bridge get pods \
  -l app.kubernetes.io/managed-by=bridge-orchestrator -L bridge.role

In the Argo Application resource tree, inspect individual worker Pods:

Worker state	Expected Argo health
Running and Ready	Healthy
Starting or draining, not Ready	Progressing
Failed, or waiting with an image error	Degraded
Completed successfully	Healthy

An overall Synced or Healthy Application does not establish worker-pool health. Workers are children of the Bridge ConfigMap rather than desired Pods declared in Git. Check the individual Pods and worker availability.

Existing workers retain their Pod specs after an upgrade. Allow normal turnover, or drain and replace workers before expecting the new probes on every Pod.

Troubleshoot

Symptom	Check
A waiting Pod reports a Lua error involving `string`	Set `resource.customizations.useOpenLibs.Pod` to `"true"` in the configuration that owns `argocd-cm`.
A ready worker still shows Progressing	Confirm the Pod health override is installed and the worker has the `app.kubernetes.io/managed-by`, `bridge.role`, and `bridge.worker_id` labels.
A draining worker still appears Ready in Kubernetes	Inspect its readiness probe. Workers created before the update need normal turnover or controlled replacement.
Argo proposes pruning runtime workers	Check that annotation-based resource tracking is configured.

Next steps

Return to the Kubernetes deployment guide for worker customization and upgrade behavior.

Last updated on September 22, 2026