SSL expiry monitor. Up to 20 hosts at once.
Paste one hostname per line. We query Certificate Transparency logs for the most-recent cert per host and render a sorted dashboard: days remaining, issuer, status band. Sub-second per host.
Paste one hostname per line, up to 20. We query crt.sh for the most-recent cert per host and render a dashboard sorted by days-remaining ascending. Most cert outages live on a sub-domain you forgot you had — bulk-checking is the cheapest way to find them.
Sub-second per host. Sorted by urgency, expired hosts at top.
Sources used
- crt.sh — Sectigo CT log aggregator
- RFC 6962 — Certificate Transparency standard
- CA/Browser Forum — moving to 47-day cert lifetimes by 2029
No data is sent to Digital Heroes servers. Each host query goes from your browser to crt.sh.
Privacy: queries go to crt.sh only; Digital Heroes doesn't log.
The cert that always expires isn't the main domain.
Every cert outage we have seen at scale follows the same pattern: the marketing site renews fine because someone owns it, the API gateway renews fine because devops owns it, and then a one-off sub-domain that nobody owns expires on a Tuesday afternoon. The campaign landing page from 2024. The status page redirect. The vendor sub-domain that points at a SaaS that auto-issues certs except when their automation breaks.
The cheapest way to catch these is a periodic bulk audit of every sub-domain you can think of. This tool runs that audit in 10-20 seconds. Paste 15-20 hostnames covering every public surface you operate, click Check, and the dashboard floats the urgent ones to the top. Make this a quarterly habit; pair it with the Subdomain Finder first to discover hosts you forgot you had.
For environments that need this on an automated schedule (alerting, PagerDuty integration, Slack notifications), invest in a real monitoring service — UptimeRobot and Checkly both do TLS expiry monitoring with alerting. This tool is for the manual quarterly audit and the moment a user reports a browser warning.
Three jobs this tool covers.
Quarterly audit. Once a quarter, paste your full sub-domain inventory and screenshot the dashboard for the engineering channel. Anything in the amber band on a manually-managed cert needs a calendar reminder. Anything in red needs a renewal today. The audit itself takes under 30 seconds.
Acquisition / vendor diligence. When evaluating a SaaS vendor, paste their full sub-domain footprint (login.vendor.com, api.vendor.com, status.vendor.com, app.vendor.com, etc.) and check expiry across the lot. A vendor with multiple expired or expiring certs across their surface area is a vendor with operational discipline issues. It's a fast, free signal during sales-cycle evaluation.
Outage triage. When users report an SSL warning, paste the affected host plus its closest neighbors (the apex, the www, the API). The dashboard tells you which cert is the problem and how stale it is. Combine with the SSL Certificate Inspector for the SAN list and issuer details on the failing host.
Six questions users ask.
Why bulk-check up to 20 hostnames?
Most cert outages happen on the second or third sub-domain — the marketing site renews fine, but the API gateway, the staging environment, or a one-off campaign sub-domain falls through the cracks. A bulk check across your whole sub-domain inventory takes 10-20 seconds and surfaces every expiring cert in one view, sorted by days-remaining ascending so the urgent ones float to the top. The 20-host cap is a courtesy to crt.sh's free public service.
How is the data sourced?
Each hostname triggers one query to crt.sh, the public Certificate Transparency log aggregator operated by Sectigo. We take the most-recent cert (sorted by entry_timestamp) and read the not_after date. Per RFC 6962, every publicly-trusted cert is logged in CT logs within seconds of issuance, so the latest CT entry is a reliable proxy for what's currently presented at the host.
What do the status bands mean?
Three bands: green (60+ days remaining), amber (1-59 days), red (expired or no cert found). Auto-renewing infrastructure (Let's Encrypt, Cloudflare, AWS ACM) typically rotates at the 30-day mark, so amber on a Let's Encrypt cert is normal short of renewal day. Amber on a manually-managed cert is a calendar reminder. Red on production is an active outage; red on a hostname that should be retired is a sign to clean up DNS.
Why does one host show 'no cert in CT log'?
Three causes: (1) the hostname has never had a publicly-trusted cert issued (private CA, internal-only); (2) the hostname is a typo or misspelling; (3) crt.sh's index lags by minutes for very fresh certs. For internal hosts, this tool is not the right instrument — use openssl s_client against the host directly. For public hosts, double-check the spelling and re-run.
Can I export the result?
Yes — click 'Copy summary' to put a plain-text table on your clipboard formatted for email, Slack, or a paste into a status doc. The table includes hostname, days-remaining, issuer short name, and not-after date. Sorted by days-remaining ascending so the most-urgent hosts surface first.
Does this tool log my hostnames?
No. Each query goes from your browser directly to crt.sh. Nothing is logged on Digital Heroes servers. There is no signup, no email field, and no analytics beacon that includes your hostname list.