Automated RCA (incident responder) — nginx-frontweb update rolled back at 06:11 CEST; service is STABLE on the previous version, no user-facing impact beyond the update window.
Root cause: upstream nginx-proxy/docker-gen published a master/CI build to the latest tag at 00:36 UTC today (0.17.2-6-g256bda4, not a tagged release). It includes PR 761, which rewrote app/docker-entrypoint.sh: the new code assigns the result of command -v on the first CMD argument to a variable while running under set -eu. Our compose service passes flag-style arguments (-notify-sighup nginx-proxy -watch ...), so command -v returns non-zero and set -e aborts the entrypoint before its docker-gen fallback line can run. The nginx-proxy-gen container exited immediately and crash-looped; the updater health probe (all containers running) failed for the full 300s window and it correctly rolled back. The simultaneously pulled acme-companion build (v2.8.1-4-g10d98eb) contains only test changes plus an internal docker-gen version bump and was almost certainly an innocent bystander, rolled back together with docker-gen.
Actions taken: diagnosis only. Nothing was restarted, deleted, or edited. The updater already restored the previous images (docker-gen 0.17.2-3-gea3bb98, acme-companion v2.8.1) and recorded the failed digests in state.json so the same digests will not be retried.
Recommendation: (1) pin nginxproxy/docker-gen (and ideally acme-companion) to versioned tags, e.g. nginxproxy/docker-gen:0.17.2, instead of latest — upstream pushes untagged master builds to latest; (2) optionally report the regression upstream (docker-gen PR 761 / issue 628: entrypoint aborts under set -e when CMD starts with a flag) — until it is fixed upstream, every new latest digest will fail and roll back again; (3) close this incident when convenient — the service itself is healthy.