Docs
Certificates, domains and DNS
Three things break a site without the server ever going down: an expired certificate, a domain registration nobody renewed, and a DNS record someone changed. Every target gets these checks with it, and none of them uses a monitor slot.
They run as long as at least one of the target's monitors is active. Pause all of them and these checks pause too.
SSL certificate
Every target whose address starts with https:// is checked every 6 hours. We read the certificate the site presents and check its expiry date and whether browsers trust it (the chain and the name). Targets added as a server or a TCP port have no SSL check.
| What we find | Alert |
|---|---|
| Expires within 14 days | warning |
| Expires within 7 days | critical |
| Expired | critical |
| Not trusted by browsers (self-signed, wrong name, broken chain) | critical |
An alert about a certificate is sent straight away, without asking a second location: a date in a certificate is the same from everywhere. If a warning turns critical, it stays one incident. Reminders follow the same schedule as for outages (see thresholds, quiet hours and reminders). The incident closes, and you get a recovery message, as soon as a check sees a renewed or fixed certificate.
Note: A certificate problem does not count as downtime: the site still answers. It has its own column (SSL) on the dashboard and its own card on the monitor's Overview. If we cannot connect at all, that is an outage and is detected as one (see how outages are detected).
Domain expiry
For every target with a domain name we look up when the domain registration expires, every 12 hours: from the registry's RDAP service, otherwise from WHOIS. We read only the date, never who owns the domain.
The lookup goes to the registered domain, not the subdomain: www.example.com, api.example.com and example.com:22 all share one registration and show the same date.
| What we find | Alert |
|---|---|
| Expires within 30 days | warning |
| Expires within 7 days | critical |
| Expired | critical |
The incident closes when the domain is renewed. Domain expiry does not count as downtime.
Note: A failed lookup never alerts and never erases a date we already know. Registries are sometimes slow or down; the last known date stays and the warning stays with it.
Warning: Some registries do not publish expiry dates:
.de,.eu,.atand.ch. For these the Domain card says so and shows–, never a green tick we cannot back up. Renewals for these domains have to be watched at your registrar.
Targets added by IP address, or with a name without a dot (localhost), have no registration and no domain expiry check.
DNS history
On the Pro plan and above, we read the target's DNS records every hour and keep a history of what changed and when. By default we track NS, A and MX (NS and MX of the domain itself, A of the target's host name).
Note: DNS history never alerts. A changed record is not an outage, and if the change breaks the site, the uptime check says so. The history is there to answer "what changed?" when something looks different.
Watching more records
On the monitor's DNS tab, under Watch more records, add up to 10 more, written as TYPE or TYPE:name, for example:
TXT:_dmarcfor DMARC on_dmarc.your host name;TXTfor SPF and other TXT records;CNAME:wwwfor thewww.in front of your host name;AAAAfor IPv6 addresses.
Types we can read: A, AAAA, NS, MX, TXT, CNAME and SOA. A new record is read right away.
Reading the history
Records now shows the current value of every record, and since when it has not changed. What changed lists changes, newest first, with the value before and after. Servers return records in a different order on every lookup, so we sort them before comparing: a reordered list is never shown as a change. The first reading of a record is a starting point, not a change.
Targets added by IP address have no DNS history: there is no name to look up.