Retire Your Renewal Monitoring Cron Job
Every engineering team eventually writes a renewal monitoring script. It starts as a one-line cron that runs openssl, parses the expiry date, and emails the team when it's under 30 days. Then it grows: it handles more domains, it adds Slack notifications, it gains a wildcard for the staging environment.
Then, sometime between months 12 and 36, it silently breaks. And the team discovers it broke when a cert expires that the script was supposed to be watching.
The ways your renewal cron decays
A non-exhaustive list of ways a homegrown cert monitoring script stops working, in roughly the order they happen:
- The OS upgrade changes openssl output format. Your parser breaks. The cron still runs, still exits 0, still produces a parse error that goes to /var/log/cron and nowhere else. The email never fires.
- The mail relay credentials rotate. The script's authenticated SMTP setup uses an old credential. Mail delivery silently fails for weeks. The alert that mattered went into the void.
- The engineer who wrote it leaves. The script lives on a single VM. The new owner finds it in the cron table but doesn't fully understand the parsing logic, doesn't know about the wildcard for staging, doesn't know which Slack webhook the URL belongs to.
- The cert list lives in a config file that drifts. A new domain gets added to production without being added to the script's domain list. The script monitors a subset of what's actually live; the gap doesn't show up until the un-monitored cert expires.
- The cron account doesn't have permission to read the cert in production. The script uses openssl s_client and works against external hostnames. It silently doesn't catch internal-only certs. Six months later, a kubernetes ingress cert lapses.
- The host gets decommissioned. Cloud migration moves the workload to a different VM, the cron isn't migrated, monitoring just stops. No one notices because the absence of alerts looks the same as the absence of problems.
- The Slack webhook rotates. Slack workspace migration changes the incoming-webhook URL. The script keeps posting to a dead URL. Nothing breaks visibly until something does.
- The script catches expiry but not chain failure. The cert is "valid" by expiry, but the intermediate CA chain isn't being sent correctly. Modern browsers handle it; older clients and some compliance scanners don't. Customer complaints arrive months before the cert was scheduled to renew.
Each of these failures is silent. The cron still runs. It still exits 0. It just isn't doing the thing you think it's doing. The first signal that monitoring failed is usually a customer ticket.
What "I'd build my own" actually buys you
Three things, usually.
Familiarity with your stack. Real. Your script knows where your certs live, knows your renewal cadence, fits into your existing alerting. This is the legitimate upside.
Sunk cost on the original engineer's time. Whatever was spent building it. Already gone, and not recoverable by keeping it running. This isn't a reason to keep it.
Avoidance of a vendor relationship. Sometimes legitimate (regulated environments, paranoid security postures). Usually a preference.
What you don't get: continuous improvement, coverage for failure modes you didn't think of when you wrote it, external validation that doesn't trust your own infrastructure, documentation that survives turnover, alerts that route to the right team without manual config, integration with the next compliance framework, and someone whose job is to know that a CA can force-revoke thousands of certificates overnight over its own compliance deadline and to check whether you're exposed before it happens.
The trade you're making
Keeping a homegrown renewal script isn't free. It costs engineering attention, on-call interruptions when it false-alarms, and outages when it silent-fails. Most teams don't measure that cost, so it doesn't show up in any spreadsheet, but it's there.
The trade is: spend engineering time on certificate monitoring, or spend it on the work that actually advances your product. The shifting PKI baseline (PQC migration, shrinking validity, distrust events, EKU restrictions) is changing fast enough that staying current on the monitoring side is becoming its own full-time job. If your team is small, it's a fraction of one person's job that's slowly eating their week. If your team is large, it's a quiet drag on the whole platform group's bandwidth.
We do this work so your team doesn't have to. The script-equivalent setup time is roughly the same. The difference is that this one keeps working when the OS upgrades, when the engineer leaves, when Slack rotates the webhook, and when Chrome changes the rules.
Replace the cron script before it silent-fails
TLS Radar handles renewal monitoring, expiry alerting, chain validation, hostname coverage, cipher and protocol checks, and OCSP revocation. Continuous, external, routed to the right team. Built to scale from a handful of sites to enterprise portfolios with API integration, SAML/SSO, and pricing tailored to your certificate volume.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.