When an `ExternalSecret` Runs on Backoff Behind a Late `SecretStore`

External Secrets Operator v2.11.0: with its SecretStore not ready, an ExternalSecret retried 1, 4, 8, 16, … seconds apart up to 7 minutes, not per refreshInterval, and synced at its next retry.

When It Runs — Run Report #RR13 · Testing what infrastructure actually does.

Provider · Component: External Secrets Operator · the first sync of an ExternalSecret whose SecretStore becomes ready late — when the controller retries the failed sync and when the Secret appears, with the flood gate on (its default)

Versions tested: measured — External Secrets Operator v2.11.0 (the current minor release as of 2026-09-28; v2.12.0, v2.13.0, v2.14.0 and v2.15.0, released on 2026-10-06, 2026-10-16, 2026-10-23 and 2026-11-10, were not measured, and v2.15.0 is the current minor release as of 2026-11-10; the project supports only the current minor version, and its support table lists 2.11's end of life as 2026-10-06), a single version. source-read — pkg/controllers/common/common.go, pkg/controllers/secretstore/ and pkg/controllers/externalsecret/externalsecret_controller.go at the same tag. The retry backoff of 1 second doubling to a 7-minute cap came with pull request #4339 (merged 2025-01-27) — a boundary taken from the pull request, not measured.

Config profile: a single-node kind cluster (kind v0.33.0, node kindest/node:v1.36.4, digest-pinned; Kubernetes 1.36 is the version the project lists for 2.11) on a dedicated test VM; the official Helm chart 2.11.0 with the controller's log level at debug; a SecretStore using the kubernetes provider against the same cluster, authenticating as a service account that exists from the start but gets its permission to read Secrets (a Role and a RoleBinding) late; an ExternalSecret with refreshInterval: 30s; three schedules — the store ready first (P0), the store and the ExternalSecret applied together with the permission 60 seconds later (P1), and the store first, the ExternalSecret 60 seconds later and the permission 600 seconds after the store (P2) — plus a repeat of P2 with an annotation change on the ExternalSecret once the store is ready (P3), all polled every 5 seconds.

Verified on: 2026-11-14 (desk sources re-checked; v2.15.0 was the current minor release) · lab measured 2026-09-28 on v2.11.0.

Affects: External Secrets Operator v2.11.0 ExternalSecrets whose first sync fails because their SecretStore is not ready yet: the controller retried on its failure backoff — gaps of 1, 4, 8, 16, … seconds, doubling to a 7-minute cap — not every refreshInterval, and did not retry when the store became ready; the Secret appeared at the next backoff retry, 64 seconds after the store became ready in one of our runs and 60 seconds in another.

TL;DR: On External Secrets Operator v2.11.0, an ExternalSecret created while its SecretStore was not yet ready retried on the controller's failure backoff — gaps of 1, 4, 8, 16, … seconds, doubling to a 7-minute cap — not on its refreshInterval: 30s, and did not retry when the store became ready: its Secret appeared only at the next backoff retry, 65 seconds after the store's permission was fixed in one schedule and 389 seconds in the other.