---------------------- Short answer: not built-in today. Garden’s Deploy dependencies wait for the apply/upgrade to complete and for Garden’s usual health checks, but there isn’t a generic “wait until this resource’s specific status/condition/jsonpath is true” feature you can declare in a Deploy spec. There’s an open feature request to add a Deploy-level waitFor option (e.g., jsonpath-based waits like kubectl wait) exactly for cases like VolumeSnapshot readiness and other eventually-consistent resources. The suggested workaround is to add an intermediate Run/exec step that performs a kubectl wait on the CR’s status before proceeding. [[FEATURE waitFor]()]. For Helm-based installs, Garden can fail fast on unhealthy resources or wait for Helm’s own timeout via spec.waitForUnhealthyResources, but that still doesn’t allow waiting on an arbitrary CR status field. [[Helm waitForUnhealthyResources](); [Edge helm waitForUnhealthyResources]()]. Workaround pattern (as in the feature request): - Deploy the CRD/CR. - Add a Run action that depends on that deploy and runs kubectl wait on the specific CR condition (e.g., cnpg Cluster’s Ready condition). - Make the dependent deploys depend on this Run action. [[FEATURE waitFor]()]. If your CR is created via Helm, you can still insert the same kubectl wait Run action between the Helm deploy and anything that depends on the CR. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

message has been deleted