SSL certificate expiration monitoring
Upcheck reads the certificate every one of your hostnames actually serves, tracks the days remaining, and tells the right people well before one lapses — by email, Slack, Discord, Teams, or webhook.
$10/month base · $1 per website · checks every 12 hours
Certificates now expire faster than teams can remember them
An expired certificate is one of the few faults that takes a site down completely and instantly. There is no degraded mode: every browser throws a full-page security interstitial, API clients refuse the handshake outright, and the failure is total from the second the validity window closes. It is also, almost always, entirely avoidable — the date was known months in advance.
What has changed is the pace. Under CA/Browser Forum ballot SC-081v3, the maximum lifetime of a public TLS certificate is on a published reduction schedule. Renewal stopped being an annual calendar entry and became a recurring operational process — and the tracking most teams rely on has not kept up with it.
Maximum certificate lifetime under the CA/Browser Forum Baseline Requirements.
Shorter lifetimes push everyone toward automated renewal, which is the right answer — but automation is not a monitoring strategy, because automated renewal fails silently by design. A DNS API token expires. A validation path moves during a deploy. The ACME client renews the certificate perfectly and the load balancer keeps serving the old one from a cache. In each case the renewal job reports success and the hostname is still minutes from an outage.
The only thing that settles it is reading what the server actually presents on a live connection, repeatedly, from outside your own infrastructure. That is precisely what Upcheck does.
Monitoring SSL certificate expiration in three steps
Add the hostnames you own
Give Upcheck a hostname and it opens a real TLS connection, reads the certificate the server actually presents, and files it under your organization. No agent, no DNS change, no code on your side.
Upcheck re-checks twice a day
A scheduled job re-runs the handshake for every website every 12 hours, so a certificate that gets replaced, revoked, or misdeployed shows up on the board within hours rather than at the next audit.
Alerts fire at your thresholds
Set the warnings that suit your renewal process — 30 days, 14 days, 7 days, on the day itself — and pick where each one lands. Rules can cover every website or just the ones that matter.
The expiry date is one field of many
A monitor that only reads notAfter tells you when a certificate dies, and nothing about whether the one in front of you is the one you meant to deploy. Upcheck stores the whole certificate on every check, so the renewal that technically succeeded but shipped the wrong chain is visible rather than latent.
Because each check is kept, you also get the diff over time: a fingerprint that changed when nobody deployed, a key size that dropped, an intermediate that vanished from the chain. Every website carries its own check history, and the workspace keeps an activity feed of what changed and who changed it.
Thresholds you choose, repeated until someone acts
An alert rule carries as many thresholds as you want it to. Warn at 30 days, again at 14, again at 7, and once more on the expiry date — from a single rule, so there is no chain of near-duplicate rules to maintain. Thresholds are expressed in days or weeks, whichever matches how your team talks about the renewal.
Each rule then picks a cadence: fire once when the threshold is crossed, daily until expiry, or every 12 hours for the ones that genuinely cannot slip. Rules apply to your whole organization by default, or you can scope one to specific websites — so the marketing site and the payments API do not have to share an escalation policy.
Delivery goes to email, Slack, Discord, Microsoft Teams, or your own webhook. Email recipients live in named lists you define once and point any rule at, which means the people who hear about a certificate can change without anyone rewriting rules. Team members are invited into the workspace with roles, so the on-call rotation and the person who owns billing are not forced to be the same account.
Every state a certificate can be in
Expiry is the failure everyone plans for. These are the ones that take sites down between renewals — each is a status on the board and can trigger the same alert channels.
Inside your warning window. This is the state the whole product exists to give you time inside of.
The certificate's validity window has closed. Browsers are now showing an interstitial to every visitor.
The certificate is present but fails validation — a broken chain, a missing intermediate, or a name that doesn't match the host.
The handshake never completed. DNS, the listener, or the network is down, and a certificate you cannot reach is one you cannot verify.
The certificate changed since the last check. Confirms automation worked — and surfaces swaps nobody scheduled.
Anything inside 21 days of expiry is flagged as expiring soon on the dashboard, independently of the alert rules you configure.
What to look for in SSL certificate expiration monitoring tools
Most certificate monitoring arrives bolted onto an uptime suite, where it is one checkbox among twenty. If certificate expiry is the thing you are actually trying to solve, these are the capabilities that decide whether it works.
Multiple thresholds per rule
One warning is a single point of failure. A tool should let one rule fire at 30, 14, and 7 days so a missed notification isn't a missed renewal.
Alerts where the team already is
An email to a shared inbox nobody reads is not an alert. Look for Slack, Discord, Teams, and a plain webhook for your own tooling.
History, not just current state
You need to answer "when did this change, and who changed it" — which means per-website check history and an activity trail.
The whole certificate, not the date
Expiry is one field. Chain, SANs, key size, and fingerprint are how you catch the renewal that succeeded but deployed wrong.
Recipients that outlive people
Certificates outlast job tenure. Named recipient lists you point rules at beat an address hard-coded by whoever set it up.
Repeat until resolved
A single notice at 30 days can be read and forgotten. Escalating repetition as the date closes is what actually gets it renewed.
Priced by what you actually monitor
$10 per month for the workspace, plus $1 per website per month. The per-website charge is metered daily, so adding a hostname mid-cycle costs only the days it was tracked, and removing one stops the charge that day. Every feature on this page is included at every size — there is no tier that withholds Slack, or webhooks, or history. A workspace can track up to 500 websites.
Frequently asked questions
What is SSL certificate expiration monitoring?
SSL certificate expiration monitoring is the practice of automatically checking the TLS certificate on each of your hostnames, tracking how many days remain until it expires, and alerting a responsible team before it lapses. A monitor connects to the host, reads the certificate the server presents, and compares its expiry date against thresholds you set — so the warning arrives with enough lead time to renew and deploy.
How often does Upcheck check for certificate expiration?
Every website is re-checked automatically every 12 hours. You can also refresh any website — or all of them — on demand from the dashboard, which runs the TLS handshake immediately and updates the certificate detail and status.
Can I monitor SSL certificate expiration for free?
You can check a certificate by hand for free with openssl s_client or an online SSL checker. That works for a single host at a single moment, but it is manual, gives you nothing when the certificate changes next month, and does not scale past a handful of names. Upcheck costs $10 per month for the workspace plus $1 per website per month.
How far in advance should I be warned before a certificate expires?
Start at 30 days. That leaves room to issue, validate, deploy, and verify without touching production under pressure. Add reinforcing warnings at 14 and 7 days, and one on the expiry date itself. If a renewal needs manual CA validation, widen the first threshold to 45 or 60 days.
Does automated renewal make expiration monitoring unnecessary?
No. ACME automation reduces how often certificates expire, but it fails quietly — a lapsed DNS credential, a changed validation path, a renewed certificate that never reached the load balancer. Monitoring reads what the server actually serves, which is the only thing your visitors experience, so it catches the gap between "renewal ran" and "renewal worked".
Where can Upcheck send certificate expiry alerts?
Email, Slack, Discord, Microsoft Teams, and your own webhook endpoint. Email alerts go to reusable recipient lists you name and point rules at, so changing who hears about a website does not mean editing every rule.
Can I monitor certificates on internal hosts?
Upcheck performs its checks over the public internet, so it monitors any hostname it can reach and complete a TLS handshake with. Certificates on hosts that are only resolvable inside a private network are out of scope.
Stop finding out from a customer
Add your hostnames, set the thresholds your renewal process needs, and choose where the warnings land.