The person who notices first is usually not the person who owns the renewal job. A browser throws an interstitial and a screenshot lands in a support channel, while the pipeline history still shows a clean run from Sunday night.
A green job is often read as proof that TLS works for the people hitting the site. What it actually confirms is narrower: a certificate authority issued a certificate [2]. The devops.com piece breaks getting a renewal into production down into renew, deploy, reload, verify and recover [12]. An ACME client's exit code speaks to the first of the five, which leaves four stages the job status does not cover [13].
The mechanism is unglamorous, which is why it survives so long. The new file has to land somewhere specific: copied to a host, mounted into a container, written to a secret, synchronised to a load balancer, or placed behind an ingress controller [4]. Then the running process has to be told to look again, because NGINX, Apache, HAProxy, IIS, application servers and custom services can each need a reload or restart depending on configuration, and until they get one the old certificate stays loaded in memory while the files on disk look perfect [5]. Drift finishes the job: a deploy script writes to one path while the service reads a different path introduced months earlier during a migration, and the script exits successfully without changing production behaviour at all [6].
Exit code 0 is doing the same work here that engagement numbers do in a product review. It records that activity happened. It does not record that anything reached a user. The correction the source proposes is a runtime check at the end of the workflow rather than at the end of a command: query the live endpoint after deploy and reload, compare the observed fingerprint, serial number, issuer or expiration against the certificate that was just deployed, and fail the workflow when they disagree even if every earlier step reported success [7]. Under that definition, success means production reached the intended state, not just that the script ran [8].
That upgrade is not free. The controls devops.com lists around automation include retries, timeouts, approval gates, failure notifications, audit trails, rollback and a way to suspend automated execution [9], seven distinct pieces of behaviour in all [14]. And the environments differ: some can renew and deploy unattended, some need an approval gate, some services support safe reloads, and legacy systems may need manual handling until their deployment process becomes predictable [15].
A cheap way to sort your own estate. Axis one: does the running service pick up new key material without human action? Axis two: does anything compare the live endpoint to what was deployed? Both yes, and renewal genuinely can be a cron entry. Reloads on its own but nothing checks, and you will usually be fine and will hear about the exceptions from customers. Needs a reload but is verified, and the job fails loudly, which is annoying and safe. Neither, and you have an outage scheduled for the expiry date with no detector in front of it. The bottom-left list is the one worth writing down, and on Kubernetes it is easy to assume it is empty: cert-manager updating a secret still leaves the questions of what consumes that secret and whether the workload reloads the material [11].
