SSL & domain expiry monitors

Some outages don’t announce themselves with a 500 — they arrive on a calendar. A TLS certificate quietly reaches its notAfter date, or a domain registration lapses, and suddenly every visitor sees a browser security warning or an NXDOMAIN. Aloft has two monitor types built specifically to give you weeks of warning.

SSL certificate expiry

An SSL monitor opens a TLS handshake to your host and reads the certificate the server presents. It doesn’t fetch a page or care about status codes — it only looks at how long the certificate has left.

• Target: a hostname (e.g. example.com) or a full URL. If you paste https://example.com, Aloft extracts the host for you.
• Port: defaults to 443. Set a different port for services that terminate TLS elsewhere (e.g. 8443, a mail server on 465).
• Alert before days: how many days of runway you want. Defaults to 14, and can be set anywhere from 1 to 365.

The monitor goes down when the days remaining drop below your “alert before days” value, and also if the certificate has already expired, if the server presents no certificate, or if the handshake fails or times out.

Note

Aloft completes the handshake to read the expiry date even if the certificate chain doesn’t fully validate, so a self-signed or misconfigured cert still reports its real expiry rather than just failing. The monitor’s job is the calendar, not chain validation.

Domain expiry

A domain monitor does a WHOIS lookup against the registry and reads the registration’s expiry date. Use it so a forgotten renewal never silently drops your domain.

• Target: a bare domain like example.com. Don’t include a scheme or path — https://example.com/login won’t validate. A leading www. is stripped automatically.
• Alert before days: same field and same default (14, range 1–365) as SSL monitors.

The monitor goes down as the registration expiry comes within your “alert before days” window, when the domain has already expired, or when WHOIS returns no expiry field Aloft recognizes. Aloft understands the common registry field names (Registry Expiry Date, Expiration Date, paid-till, and several more), but some exotic TLDs publish dates in formats it can’t parse — if you see “WHOIS returned no expiry field we recognise”, that domain isn’t a good fit for automated monitoring.

Reading the detail page

Open any SSL or domain monitor and you’ll see a dedicated Certificate expiry / Domain expiry card instead of the usual response-time tiles and chart. It shows one of:

• “N days left” — the runway remaining, counting down toward your alert threshold.
• “Expired” with “N days ago” — the certificate or registration has already lapsed.
• A note that there’s no probe data yet, until the next scheduled check runs.

The card’s subtitle reminds you of the threshold: “Alert fires when fewer than N days remain.”

Why no response-time chart?

For these monitors, Aloft repurposes the “response time” field to store days-until-expiry, so the millisecond chart and “average response” tile would be meaningless. They’re hidden on purpose — the expiry card is the real readout.

When to use them

• SSL: any public HTTPS endpoint — your main site, API hosts, admin panels, internal services with their own certs. Especially valuable for certs you renew manually rather than via automated ACME.
• Domain: every domain you own that matters, including ones that just redirect. Registrar auto-renew can and does fail (expired cards, billing disputes), so don’t assume it has you covered.

Both run on the same schedule as every other monitor — see Scheduling & confirmations. Hook them up to a channel so the warning actually reaches you; once a monitor goes down, Aloft opens an incident.