cert-manager handles TLS certificate renewals in the background before they reach expiration, preventing unexpected downtime and eliminating manual tracking. This page explains how automatic renewal intervals work, how to monitor certificate status, manually trigger rotations using `cmctl`, and how to set up alerting against renewal failures.

**Before you begin**, ensure [cert-manager is installed](/docs/hetzner/apalla/network/dns-certs/install-cert-manager) in your cluster. For manual certificate operations and troubleshooting, install [cmctl](https://cert-manager.io/docs/reference/cmctl/) (the cert-manager CLI).

## Automatic renewal

cert-manager schedules renewals based on the `renewBefore` window defined on each `Certificate`. By default, it attempts renewal when two-thirds of the certificate's validity has passed (30 days before expiration for a standard 90-day Let's Encrypt certificate), providing ample time to retry if ACME challenges or DNS propagation fail. You can customize this renewal window directly in the `Certificate` spec:

```yaml
spec:
  renewBefore: 720h # renew 30 days before expiry
```

When cert-manager renews, it writes the new certificate into the same Secret. An ingress controller watching that Secret loads the new certificate and serves it, with no restart and no dropped connections.

## Watch and inspect a certificate

Check the status of your certificates with `kubectl`:

```console
$ kubectl get certificate
NAME                  READY   SECRET                 AGE
app-example-com-tls   True    app-example-com-tls    60d
```

To view the exact renewal schedule and lifecycle events, describe the `Certificate` resource:

```console
$ kubectl describe certificate app-example-com-tls
...
Status:
  Conditions:
    Message:               Certificate is up to date and has not expired
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2026-11-30T12:09:48Z
  Not Before:              2026-09-01T12:09:48Z
  Renewal Time:            2026-10-31T12:09:48Z
Events:
  Type    Reason   Age   From                               Message
  ----    ------   ----  ----                               -------
  Normal  Issuing  33s   cert-manager-certificates-trigger  Issuing certificate as Secret does not exist
  Normal  Issuing  33s   cert-manager-certificates-issuing  The certificate has been successfully issued
```

Key fields to check:

- **`Status.Conditions`:** `Ready: True` confirms the certificate is issued and valid in the target Secret.
- **`Status.Renewal Time`:** The exact calculated timestamp when cert-manager will automatically initiate renewal.
- **`Status.Not After`:** The certificate's final expiration timestamp.
- **`Events`:** Displays step-by-step controller actions. If renewal fails, the error message surfaces here.

## Force a renewal

To rotate ahead of schedule, for example after a suspected key exposure, trigger a renewal with the cert-manager CLI:

```console
$ cmctl renew app-example-com-tls
```

cert-manager requests a fresh certificate and updates the Secret. Do not rotate in a tight loop; each renewal is an actual request against the certificate authority.

## Alert before expiry

Automatic renewal operates seamlessly in normal conditions, but solver failures (such as expired DNS provider tokens, misconfigured ingress challenge routes, or DNS propagation delays) can cause renewals to stall unnoticed. To prevent outages, alert on remaining certificate validity well before expiration.

cert-manager exposes the `certmanager_certificate_expiration_timestamp_seconds` metric across all managed certificates. Configure an alert rule to fire when remaining validity drops below a safe threshold, such as 14 to 21 days:

```promql
(certmanager_certificate_expiration_timestamp_seconds - time()) < (14 * 86400)
```

Because cert-manager initiates renewal 30 days before expiration, an alert firing at 14 days signals that renewal attempts have been failing repeatedly for over two weeks, giving your team time to fix solver issues before certificates lapse.

Certificate monitoring in Syself Autopilot separates workload certificates from node infrastructure certificates:

- **Workload certificates:** Tracked via cert-manager's Prometheus metrics for your application Ingresses.
- **Node platform certificates:** Monitored by the Syself node health daemon, which emits the `CertRenewalFailing` node condition and the `autopilot.syself.com/certs` annotation. See [Certificate expiry and rotation](/docs/hetzner/apalla/servers-and-nodes/access/certificate-expiry-and-rotation).

For production `PrometheusRule` manifests and alert routing configurations, see [Platform alert rules](/docs/hetzner/apalla/observability/alerting/platform-alert-rules#certificate-expiry).

> [!NOTE]
> A failed renewal backs off and retries automatically without overloading the certificate authority. If renewals continue to fail, resolve the underlying solver error (such as DNS-01 API credentials or HTTP-01 route reachability) rather than repeatedly forcing renewals, which can exhaust Let's Encrypt's domain rate limits.

<Collapsible title="CA and intermediate rotation">

When a certificate authority rotates its intermediate, cert-manager adopts the new chain on the next renewal, so your certificates continue validating without action. If you run your own CA `Issuer`, rotating that CA's key means every certificate it signed must be re-issued: plan the rotation so the old and new CA are both trusted during the overlap, then renew the leaf certificates.

</Collapsible>

## Where to go next

- [Set up a Let's Encrypt ClusterIssuer](/docs/hetzner/apalla/network/dns-certs/lets-encrypt-clusterissuer)
- [Install cert-manager](/docs/hetzner/apalla/network/dns-certs/install-cert-manager)
- [Platform alert rules](/docs/hetzner/apalla/observability/alerting/platform-alert-rules)