SSL, DNS and domain-expiry monitors
Three monitor types watch the infrastructure around your site: the SSL/TLS certificate, the DNS records, and the domain registration itself. All three are created from /monitors/create like any other monitor; each is described below with its exact configuration fields.
Note: The "Monitor a whole site" quick-add at /monitors/site creates all three (plus uptime, security headers and email security) for a domain in one step, with sensible intervals — daily for certificate and domain expiry, hourly for DNS.
SSL/TLS certificate monitors
Type: SSL/TLS certificate. CompleteStatus opens a TLS connection to your host, inspects the certificate and the negotiated connection, and grades it SSL-Labs-style from A+ to F.
Configuration
- Target — the hostname (a full URL also works; the host is extracted).
- TLS port — default 443. Point it at 8443, 993 (IMAPS), etc. for non-web TLS services.
- Interval — daily is typical; certificates don't change often.
What gets checked and graded
Each check records the expiry date and days remaining, issuer, subject and SANs, key type/size, signature algorithm, negotiated protocol and cipher, serial, SHA-256 fingerprint, and whether the chain validates against trusted roots.
Grading starts at 100 and subtracts per finding:
| Finding | Effect |
|---|---|
| Certificate expired | Automatic F |
| Protocol below TLS 1.2, RSA key < 2048 bits, EC key < 256 bits, SHA-1/MD5 signature | Automatic F |
| Chain does not validate | −40 |
| Expires in < 7 days | −30 |
| Hostname not covered by the certificate's SANs/CN | −20 |
| Expires in < 14 days | −15 |
| Expires in < 30 days | −5 |
| Negotiated TLS 1.2 (1.3 preferred) | −5 |
Scores map to grades: 100 → A+, ≥90 → A, ≥80 → B, ≥70 → C, ≥60 → D, else F.
When it alerts
The check fails (feeding the normal two-consecutive-failures state machine) when the chain is invalid, the certificate is expired, or the grade drops below C. On top of that, two dedicated alert-rule events exist on the monitor's Alert rules panel: cert_expiry and grade_drop — tick them on a rule to be notified about expiry and grade regressions specifically.
The expiry deductions above act as built-in warning thresholds at 30, 14 and 7 days. The thresholds are fixed — there is no per-monitor "warn me N days before expiry" field.
Even a self-signed or otherwise invalid certificate is still inspected and reported (the check reconnects without verification so it can show you what's wrong rather than just "handshake failed").
TLS configuration monitors
Type: TLS Configuration. Where an SSL certificate monitor grades the certificate, a TLS-configuration monitor grades the server's TLS stack — the protocol versions and ciphers it will actually accept. It's the configuration counterpart to certificate monitoring.
What gets checked and graded
On every check, CompleteStatus forces a separate, read-only handshake for each of TLS 1.0, 1.1, 1.2 and 1.3 (a plain ClientHello — no payload is ever sent) to discover exactly which protocols the server accepts, not just the one a normal browser happens to negotiate. It records the cipher negotiated for each accepted protocol and grades the result A+ to F:
- A server that refuses everything below TLS 1.2 and negotiates modern ciphers grades high.
- Accepting the long-deprecated TLS 1.0 or 1.1, or a weak cipher, caps the grade.
- A server that offers neither TLS 1.2 nor 1.3 is a hard F.
Configuration
Point the monitor at your host; the port defaults to 443. The check resolves and pins the host through the SSRF guard first (identical posture to certificate checks — no private/internal targets, no DNS-rebinding).
When it alerts
The monitor passes only while its grade is B or better. A configuration change that starts accepting a deprecated protocol or weak cipher drops the grade and fails the check, opening an incident through the normal flow — the same grade_drop alert-rule event applies.
Certificate Transparency monitors
Type: Certificate Transparency. CompleteStatus queries the public crt.sh Certificate Transparency log aggregator for every certificate issued for your domain and diffs the result against the previous run to surface newly-issued certificates — an early warning for mis-issuance or an unauthorized certificate a CA issued for your domain without your knowledge.
How it behaves
The first run records a baseline of the certificates already known for the domain; later runs report any certificate that wasn't in the baseline as a new-cert event you can review on the monitor.
This monitor is informational — it never opens a "down" incident. Legitimate renewals issue new certificates too, so a new cert would flap an alert on every renewal; instead it stays healthy (ok) and records the new certificates under the monitor's detail for review. crt.sh is frequently overloaded, so any unavailability soft-fails (the monitor stays healthy and the baseline is left intact) rather than reporting a flood of false "new" certs. Because it's a polite, read-only public-log query, it runs at most daily.
DNS record monitors
Type: DNS. CompleteStatus resolves your chosen record types on every check, snapshots the answers, and diffs them against the previous snapshot. An unexpected change fails the check — catching hijacks, botched migrations and unauthorized edits.
Configuration
- Target — the hostname to resolve.
- Record types — any of A, AAAA, MX, NS, TXT, CNAME (at least one; default A).
- Allowlist — values or regex patterns for records that are expected to change (round-robin IPs, dynamic TXT records). Matching additions/removals are suppressed and won't alert. Example:
192.0.2.\d+.
How change detection works
- The first check is the baseline — it always passes and stores the snapshot.
- Every later check diffs current records against the last snapshot, per record type, listing exactly what was added and removed.
- Any non-allowlisted change fails the check with "DNS records changed unexpectedly." After a second consecutive failing check the monitor goes down and an incident opens with the diff in its detail.
- Each check stores a fresh snapshot (the last 50 are kept), so after you acknowledge a legitimate change the next check passes against the new baseline.
The check also reports best-effort DNSSEC detection (whether signing records were seen in the zone).
Note: If your records rotate by design (CDNs, load balancers), add allowlist patterns up front — otherwise every rotation opens an incident.
Domain-expiry monitors
Type: Domain expiry. CompleteStatus queries the public RDAP registry data for your domain and computes days until the registration expires.
Configuration
Just the target (the domain) and an interval — daily is right. There are no type-specific fields.
What gets recorded
Each check stores the expiry date, days remaining, registration date, registrar name and the domain's registry status codes (like clientTransferProhibited).
When it alerts
- The check only fails when the domain has actually expired (days remaining ≤ 0) — that is what opens an incident.
- Before that, built-in thresholds at 60, 30, 14 and 7 days are recorded on each result, and results within 30 days of expiry carry a warning ("Domain expires in N day(s)") that surfaces in the UI.
- If the registry lookup itself fails (RDAP outage, unsupported TLD), the check reports "unknown" but stays passing — a flaky registry never pages you.
Related guides
- HTTP uptime monitors — shared fields, intervals and the down-confirmation state machine.
- Getting started — alert channels and routing rules.
- API monitors and assertions — asserting on API responses.
Further reading on the blog: SSL certificate monitoring, 47-day certificates are coming and Domain expiry — the outage nobody monitors.