Use case

Catch the expiring TLS cert before your users do.

A TLS certificate hits 0 days remaining at 03:42 on a Saturday and the on-call thread starts five minutes later. You wanted a calendar reminder, but the renewal cycle slipped past the auto-renew window because the ACME script silently broke three months ago. Crontap fires a scheduled probe against your hostname every day, parses the cert chain, and pages you the moment days-remaining drops under the threshold you set.

Get started

Free plan · no credit card required

The problem

Why this is painful without the right tool

  • Auto-renew tooling (Certbot, cert-manager, Caddy) is supposed to handle this — until it doesn't. The script fails silently, the cron daemon is paused, the rate-limit ban kicks in, and you find out from a customer.
  • Browser-side warnings start firing at 30 days remaining for some clients (mobile Safari, some corporate proxies). 'It worked yesterday' is the bug report you'll get.
  • Multi-domain orgs lose track. The 12 subdomain certs are on 4 different renewal systems and the spreadsheet someone made in 2023 isn't being maintained.
  • Internal-network certs (mTLS, internal API gateways) have no public ACME path and rely on a quarterly manual reissue that gets forgotten.
  • Cron monitoring tools (Cronitor, Healthchecks) are great for the renewal job firing, not for the resulting cert actually being valid.

The fix

How Crontap solves it

Try the free SSL expiry checker first to see what the probe finds (paste a hostname, get back issuer, validity window, SANs, days remaining). Then wire it as a recurring Crontap schedule against the same hostname. Once a day at 09:00 local is plenty; once an hour is overkill but cheap. The schedule fires a small server-side endpoint you control that re-runs the same check, and Crontap emails when the response says "expires in fewer days than you specified".

cron expression
0 9 * * *
Daily at 09:00 in your timezone, probe https://api.example.com. The handler parses the cert chain and returns 5xx if days-remaining < 14. Crontap emails the moment the threshold trips; you get 2 weeks to renew without a 03:42 page.

The pattern is the same shape as any HTTP cron with Crontap, with one extra: the handler does the cert inspection in your code and returns the status you care about. A 12-line Node handler does this with tls.connect():

tls.connect(443, hostname, { servername: hostname }, () => ...; the socket's getPeerCertificate() returns valid_to as an ISO date. Subtract from Date.now(), compare to the threshold, return 500 if under. Crontap retries 5xx with backoff and emails when retries are exhausted. The same shape works for Python (ssl module), Go (crypto/tls), or Bash (openssl s_client).

For domains you don't host yourself (third-party SaaS, internal APIs you're a consumer of), the free SSL expiry checker is the one-off check; pair it with a Crontap schedule against a small probe endpoint you run that wraps the same check, so you get a tracked daily run plus an alert.

Pricing: free Crontap plan covers one schedule + one uptime monitor (enough to track your primary cert). Pro unlocks unlimited schedules at minute cadence for the multi-domain case.

FAQ

Common questions

Why not just use Certbot's renewal hook?
You should. The renewal hook is the right place to react on a successful renewal. The pattern on this page is the safety net that catches the case where the hook never fired (Certbot was paused, the cron daemon died, the script crashed). Daily external check + hook on success is the belt-and-suspenders combination.
Does Crontap natively probe SSL certificates?
Crontap fires HTTP cron and runs URL uptime probes. The SSL inspection is in your handler (12 lines of Node / Python / Go / Bash). The free SSL expiry checker tool runs the same probe in-browser if you just want a one-off look.
What threshold should I use for the alert?
Industry default is 30 days as the warn level and 7 days as the page level. Set both as separate schedules with different alert routes (warn to email, page to Slack on-call channel). Mobile Safari and some corporate proxies start showing warnings at 30 days for non-Let's-Encrypt certs.
Will this catch a fully expired cert?
Yes — the schedule will fire, the handler will return 5xx because days-remaining is negative, and you'll get the email. But you'd much rather catch it 14 days before expiry, which is what the threshold pattern is for. Don't wait for the cert to actually expire to find out.
What about wildcard or multi-SAN certificates?
The probe returns the cert at the primary hostname including all SANs. If you have a wildcard *.example.com, probing any.example.com gets you the expiry of the wildcard. Multi-SAN certs (one cert covering api.example.com + admin.example.com + ...) are inspected the same way.

Ready to fix it?

Point Crontap at any URL. Pick any cron. Done.

WordPress, Shopify, Railway, Cloud Run, Vercel, HubSpot, Ghost, your own box. If it answers HTTP, Crontap can drive it on a clock you can read, in the timezone that actually matters, and page you when something breaks.

Free forever tier ・ No credit card required

GET

/wp-cron.php?doing_wp_cron=1

Running
Your next schedule

Schedule

"every 5 minutes"

Next

in 23s