Expiry monitoring
Two expiry dates, two very different mornings after.
Almost every outage is a surprise. These two are not: a TLS certificate and a domain registration both carry an expiry date that is public, machine-readable and set months or years in advance. Expiry monitoring reads those dates on a schedule and alerts you with as much lead time as you ask for. One monitor type for the certificate, another for the registration, because they fail on completely different timescales and want completely different responses.
How it works
The SSL monitor opens a TLS connection to the host and reads the expiry date out of the certificate the server presents. The domain monitor asks the registry over RDAP, using IANA's bootstrap to find the authoritative server for that TLD, so the answer comes from the registry rather than a third-party lookup service. Both compare the remaining days against a lead time you set per monitor, anywhere from 1 to 90 days, and both alert through the same channels as the rest of your monitors.
Your benefits
- One place that answers “what lapses next”
- Independent of registrar reminder mails and renewal automation
- Lead times set per monitor, from 1 to 90 days
- Certificates on any port, not just 443
- Registry data straight from RDAP, no reseller in between
What you get
The exact expiry date and remaining days for every certificate and domain you track, plus an alert at the lead time you chose.
Availability
Which monitor types your plan includes is listed on the pricing page, alongside the number of monitors.
A certificate costs you minutes, a domain costs you the name
They get confused constantly, and the confusion is expensive. A TLS certificate typically lives 90 days and renews itself; when that fails, browsers show a warning page and you fix it in minutes once you know. A domain registration lives for years, and when it lapses a chain starts that you do not control: resolution is switched off, a redemption period with three-figure recovery fees begins, and then the name drops and is taken by a broker within seconds. Same word, same kind of date, entirely different stakes. That is why they are separate monitor types with separate lead times, rather than one checkbox pretending both are the same problem.
The monitor depends on neither a distribution list nor renewal automation
Both a registrar and a certificate authority will happily email you before something expires. In practice those mails land in a distribution list nobody reads, in the mailbox of someone who left, in spam, or, best of all, at an address on the very domain that is about to stop resolving. Renewal automation has the same shape of problem: it works until a hook is lost in a migration or a challenge stops validating, and it does not tell you when it has stopped. Monitoring from the outside depends on none of that. It asks the host and the registry directly, and it alerts through channels you picked and actually watch.
DENIC answers RDAP for .de, just without the expiry date
For certificates the source is the host itself, so anything reachable over TLS can be monitored, including internal and self-signed certificates, since the check reads the expiry date without judging the trust chain. For domains the source is the registry, and there the limit is not ours: every gTLD such as .com, .net, .org, .dev or .app must publish an expiry date via RDAP, and many ccTLDs like .fr, .uk, .nl and .pl do too. Several deliberately do not, among them .de, .at, .ch, .eu, .be, .es and .io. DENIC answers RDAP for .de but omits the expiration event as a matter of policy. No tool can work around that, so we reject the monitor at creation time and say which TLD is unsupported, rather than handing you one that stays red forever.
Frequently asked questions
Can I monitor domain expiry and SSL alerts together?
Yes, and that is the usual setup: a domain-expiry monitor on the registration and an SSL monitor on each host that terminates TLS. They are separate monitors so each can carry its own lead time, typically weeks for a certificate and months for a domain. They alert through the same channels and appear side by side in the dashboard.
How far ahead does it warn?
You choose per monitor, from 1 to 90 days, with 7 as the default. For ACME certificates 14 to 21 days is a good range, since automation normally renews at 30 days remaining. For domains, go wider: 60 to 90 days leaves room for a registrar transfer or a billing problem to be sorted out.
Does it work for domains registered anywhere?
It works wherever the registry publishes an expiry date over RDAP, which covers all gTLDs and many country domains, regardless of which registrar you bought through. It does not work for TLDs that withhold the date, including .de, .at, .ch, .eu, .be, .es and .io. Those are rejected when you create the monitor, so you find out immediately rather than later.
What if the certificate isn't on port 443?
Write the target as host:port. Mail, LDAP and broker certificates are the ones that most often go unnoticed, precisely because their expiry produces no warning page, just mail that quietly stops being delivered.
Do I still need this if I use Let's Encrypt?
Arguably more so. Short-lived certificates mean renewal happens dozens of times a year, and each one is a chance for a hook, a challenge or a cron job to fail silently. The monitor is what turns a broken renewal into a notification instead of an outage.
Where do the alerts arrive?
Email, Slack, Discord, Telegram, PagerDuty, Opsgenie, ntfy, Gotify, webhooks, MQTT, or push on the Android app. Channels are set per monitor, so an expiry warning can go somewhere calmer than a 3 a.m. outage page.