An expired TLS certificate can turn a healthy website into a browser warning within minutes. Automated renewal reduces the risk, but it does not prove that every domain, load balancer, and edge endpoint is serving the correct certificate. A scheduled web cron check provides independent warning before users are affected.
Monitor the endpoint users actually reach
Connect to each public hostname over TLS and inspect the certificate presented by that endpoint. Do not check only a certificate file stored on the origin server; a CDN, reverse proxy, alternate region, or stale load balancer may serve something different.
Maintain an inventory of production hostnames, ports, expected organizations or issuers where appropriate, and the service owner responsible for renewal.
Record more than the expiration date
Capture the not-before and not-after times, subject alternative names, issuer, serial or fingerprint, negotiated protocol, and chain validation result. Confirm that the requested hostname is covered and the chain reaches a trusted root.
A certificate with months remaining can still be wrong if the hostname is missing, the chain is incomplete, or a deployment serves the certificate for another environment.
Use several warning thresholds
One alert near expiration leaves little recovery time. Use escalating windows such as an early notice for investigation, a higher-priority warning near the renewal deadline, and a critical alert before likely user impact.
Choose thresholds based on the renewal method and change process. Certificates that require manual validation or coordinated deployment need more lead time than fully automated certificates.
Run frequently enough to detect bad deployments
A daily check is often sufficient for expiry planning, but important endpoints may justify checks every few hours to catch a newly deployed invalid chain or hostname mismatch. Keep each run bounded and apply reasonable network timeouts.
Schedule and store times in UTC, while displaying local context to responders. Our guide to time-zone-safe cron scheduling prevents maintenance windows from moving unexpectedly.
Protect the monitoring endpoint
If the cron service triggers a private checker, authenticate the request and reveal no internal host inventory or certificate details in the HTTP response. Use HTTPS, strict methods, rate limits, and least-privilege execution.
Apply the patterns in securing web cron endpoints to the trigger and keep diagnostic results in protected storage.
Deduplicate and resolve alerts
Create a stable alert key from the hostname, port, certificate fingerprint, and condition. Repeated checks should update one open incident rather than send a new message every hour.
Send a recovery notification when a valid renewed certificate is observed consistently. Require one or more successful checks if propagation across multiple edges can be gradual.
Check multiple network paths
DNS and CDN routing can present different certificates by region or address family. For critical services, test IPv4 and IPv6 and sample relevant regions or edge locations. Record the resolved address with each observation.
Do not assume one successful edge represents the whole service. Compare fingerprints and expiry times to identify partial rollouts.
Plan for renewal, deployment, and rollback
An alert should link to an owned runbook: how renewal starts, where the new certificate is stored, which systems must reload, how validation is performed, and how to roll back. Separate certificate issuance from deployment verification.
After renewal, verify the public endpoint, full chain, hostname coverage, and expected expiry—not merely that the automation command exited successfully.
Use reliable delivery channels
Route early notices to the owning team and critical alerts to an on-call channel. Track whether delivery succeeds and avoid depending only on email hosted behind the same expiring domain.
The delivery design in scheduled email reports shows how idempotent messages, recipient-level state, and provider events improve notification reliability.
Monitor the monitor
Record check duration, connection errors, validation results, days remaining, alert state, and last successful observation. Alert when the scheduled checker itself stops running or its inventory becomes empty.
Use the signals in cron job monitoring so a missing check cannot look like a healthy certificate.
Test failure cases safely
Test against endpoints with expired, self-signed, hostname-mismatched, incomplete-chain, and not-yet-valid certificates. Simulate DNS failures, timeouts, partial edge deployment, alert retries, and recovery.
Follow the web cron testing checklist before depending on the checker for production response.
Implementation checklist
- Inventory every public TLS hostname and owner.
- Inspect the certificate served by the real endpoint.
- Validate dates, hostname coverage, and the full chain.
- Use escalating warning thresholds and deduplicated incidents.
- Test relevant regions, IP families, and edge paths.
- Verify renewal deployment and send recovery notifications.
- Monitor missed checks as well as certificate failures.
Certificate monitoring is most useful when it is independent of renewal. By checking the endpoint users reach, validating the full TLS result, escalating early, and confirming recovery, a web cron job can catch both forgotten renewals and broken deployments.