Automate SSL Certificate Expiry Checks

By the HostTracker Team - published August 2026

Somewhere between a certificate that renewed itself last year and one that needed a manual step nobody remembered, a production site goes dark behind a browser warning. Visitors see "Your connection is not private," support tickets pile up, and the team usually finds out about the expiry not from a dashboard but from a customer's screenshot. It is one of the most common outages in web operations, and also one of the easiest to prevent, once you stop relying on a person to remember.

Why a calendar reminder is not enough

A calendar reminder works for one certificate, on one domain, renewed on a fixed schedule, by one person who never changes teams or goes on vacation the week it is due. Real infrastructure rarely looks like that. A single company can be running certificates across a dozen subdomains, a wildcard certificate covering all of them at once, an intermediate certificate a certificate authority rotates without much notice, and a handful of one-off certificates issued at different times because a service was added later and nobody updated the tracking sheet.

Automated renewal removed a lot of the manual work, but it also removed the visible signal that used to tell someone "this happened." When automated renewal quietly fails, a config points at the wrong certificate file, or a subdomain was simply never added to the automation in the first place, nothing tells you until a browser does, in front of a visitor.

Level 0: check a certificate right now, for free

Before setting anything up, it helps to know where you stand today. HostTracker's free SSL certificate checker at /en/ic/ssl-check runs a one-off check against any URL and returns a certificate-focused view of the result: issuer, expiry date, and any handshake problems. No account is required, and under the hood it is the same check engine that runs the rest of the product, just presented with certificates in front.

Run in strict mode, the checker validates the TLS handshake the way a certificate audit should, and it catches problems a relaxed uptime-style check quietly waves through. It reports:

• an expired certificate
• a self-signed certificate
• a certificate chaining to an untrusted root
• a certificate issued for a different hostname than the one you checked

That is a meaningfully different result from an ordinary uptime check, which will happily report a self-signed or wrong-host certificate as fine, since all it cares about is whether the page answers; expiry was the one certificate problem it always caught anyway, because an expired handshake fails outright. There is one edge case strict mode still cannot see: a server missing an intermediate certificate but whose root can still be resolved automatically. The checker builds the trust chain the same way a browser does, filling that specific gap in for you, so a genuinely broken chain a visitor would never notice can, in that one case, go unflagged too.

Level 1: get notified before it expires, not after

A one-off check is a snapshot. What actually stops the surprise is turning that same check into a monitor that runs on its own and warns you before your visitors notice anything. Add the certificate's host as a monitor, choose how far ahead of the expiry date you want to hear about it, and HostTracker checks on your interval from then on, no new dashboard to learn, since it is built on the same check type behind the free page, just running continuously and tuned to warn you early instead of only reporting after the fact.

When something needs attention, HostTracker sends the alert through the contacts and channels already configured on your account, including webhooks if you want the event routed straight into your own incident tooling, so nobody has to remember to look. Set it up once and a lapsed renewal becomes an alert on your terms, days ahead, instead of an outage you hear about from a customer.

Setting this up needs a HostTracker account. Sign up to start, or see the plans for what is included at each tier.

Level 2: automating certificate checks across a fleet of domains

A handful of certificates are easy to watch by hand. Fifty domains spread across several teams are not. That is where the CLI and the API earn their keep: the same strict TLS validation as the checker page, run from HostTracker's 300+ checkpoints, scripted across as many domains as you own.

From the command line

ht-cli drives HostTracker's API v2 from a shell, and its check command is built for exactly this. Install it (Homebrew, an install script, a Linux package repo, Docker or go install, all covered on the CLI page), log in once, and run a strict check against any host:

ht-cli auth login
export HT_TOKEN=...
ht-cli check run https://your-domain.com --strict-tls --wait

--strict-tls validates the TLS handshake strictly instead of the relaxed handshake an uptime check wants: an expired certificate, an untrusted root, a name mismatch or a self-signed certificate fails the check outright. Point the same command at every domain you own and you have a script; put that script on a schedule and you have a certificate monitoring script that needs no dashboard at all:

# crontab entry - run every morning at 06:00
0 6 * * * HT_TOKEN=$(cat /etc/hosttracker/token) ht-cli check run https://your-domain.com --strict-tls --wait -o json >> /var/log/ssl-check.log

Loop that line over a list of hostnames and feed the JSON output into whatever already pages your team. The CLI's own exit codes (a rejected credential, an address that resolves to nothing, a throttled request) tell you when the command itself could not run, separately from what the check found. The CLI is open source at github.com/HostTracker/cli if you want to see exactly what it does before pointing it at production. For a fuller walkthrough of the other 138 commands, see our CLI article.

From CI, before you deploy

The official GitHub Action gives a deploy-time uptime gate in a couple of lines:

- uses: HostTracker/check-action@v1
  with:
    token: ${{ secrets.HT_TOKEN }}
    mode: assert-up
    url: https://www.example.com

The action does not expose the strict-TLS flag directly today, so for a certificate-specific gate in the same workflow, call the CLI instead. It installs in one line and needs nothing but an environment variable in CI:

- name: Verify certificate before release
  env:
    HT_TOKEN: ${{ secrets.HT_TOKEN }}
  run: |
    curl -fsSL https://raw.githubusercontent.com/HostTracker/cli/main/install.sh | sh
    ~/.local/bin/ht-cli check run https://your-domain.com --strict-tls --wait

The Action itself is on GitHub at HostTracker/check-action.

From your own code

Everything above is one call to the API v2 endpoint that starts an instant check, POST /check, with strictTls: true in the body:

curl -X POST https://api2.host-tracker.com/check   -H "Authorization: Bearer $HT_TOKEN"   -H "Content-Type: application/json"   -d "{\"url\": \"https://your-domain.com\", \"type\": \"http\", \"strictTls\": true}"

If you are already writing Python, JavaScript, Go or .NET, the official SDKs wrap the same endpoint in a typed client instead of raw HTTP, covered in this wave's SDK article. The full endpoint-by-endpoint reference for everything above lives on the API v2 docs page, and a broader tour of the API surface is in our API guide.

What is free and what needs a plan

Worth being upfront about, since the answer differs by layer. The instant checker at /en/ic/ssl-check is free to use, no account needed, for a one-off look at any certificate. Programmatic access, meaning the CLI, the SDKs, the API, and by extension any script or CI job built on top of them, sits on a different tier: the Free, Personal and Webmaster plans do not include API access at all, so this whole automation layer needs Business, Enterprise, or the 30-day free trial, which requires no card to start. Continuous monitoring lives on your account regardless of how you talk to it; the difference is only whether you are clicking a button or calling an endpoint.

Put it together

Manual certificate tracking works right up until it does not; one more domain, one more team, one missed renewal is usually all it takes. Layer the three levels instead: check a certificate for free with the checker when something looks off, put a monitor with a lead time on every domain that matters so you hear about a problem before a visitor does, and script the same strict validation into cron or CI once you are managing more than a handful of hosts. See also the CLI article and the wider monitoring API for the rest of what the same account can automate, and start a trial whenever you are ready to script it.