Domain and SSL certificate expiry

An expired domain or certificate is an outage with a calendar date on it, which makes it the most avoidable kind. AlertKick tracks both from the outside, on a schedule, and routes the warning through the same escalation policies as any other alert. Domain and SSL checks are two of the five monitor types (see Monitor types) and are included on every plan.

Domain expiry monitors

A Domain Expiry monitor looks up the registration record for a domain and alerts when the expiry date falls inside the lead time you set.

What is checked

The lookup uses RDAP, the registries’ structured successor to WHOIS, via the IANA bootstrap redirector so each query lands at the authoritative registry. From the record the monitor reads:

• Expiry date and the days remaining.
• Registrar name and IANA ID.
• Registration status codes, including whether a transfer lock (transferProhibited) is set.
• Registered and last changed dates.
• Nameservers delegated for the domain.

Alongside the registry record the check gathers a best-effort DNS and mail profile - apex and www addresses, MX records, SPF and DMARC records - shown on the monitor’s detail panel. That part never fails the check; it is context for the person reading it.

You can paste a full URL as the target. Scheme, path, port, and trailing dots are stripped and only the registrable domain is queried.

Lead time and interval

Setting	Field	Default	Range
Warning lead time	domain_expiry_alert_days	30 days	1 to 365
Check interval	check_interval_seconds	24 hours	plan minimum and up

The check fails, and the alert path starts, once days_remaining <= domain_expiry_alert_days. One lead time applies per monitor; create a second monitor on the same domain if you want a separate, closer warning.

The monitor also emits domain_unlocked and domain_locked events when the transfer lock changes state, and publishes a days_to_expiry metric so the countdown appears on the monitor chart.

Limitations

• Some country-code registries do not publish an expiry date over RDAP. The check reports “registry did not report an expiration date” and the monitor shows as failing rather than silently passing.
• Nameserver and registrar changes are recorded on the monitor but do not raise their own event. Use a DNS monitor on the records themselves to alert on answer changes.
• On-premise pollers need v1.1.0 or newer to run domain checks; older pollers ignore the monitor. See On-premise pollers.

SSL certificate expiry

Certificate tracking is a setting on an HTTP/HTTPS monitor rather than a separate type. When the URL is https://, the create form shows SSL certificate monitoring with its own lead time:

Setting	Field	Default
Enable certificate monitoring	ssl_cert_monitoring	on for HTTPS URLs
Warning lead time	ssl_cert_expiry_alert_days	30 days

The monitor records the certificate’s expiry date, issuer, and days remaining, and raises an ssl_expiry event with the message “SSL certificate expires in N days” once the countdown crosses the lead time.

Because the check reads the certificate the server actually presents, it catches the case an expiry reminder cannot: a certificate that was renewed on disk but never reloaded, or a load balancer still serving the old one. Independently of the lead-time warning, an expired, mis-hosted, or untrusted certificate makes the HTTPS check itself fail with a TLS verification error, so the monitor goes down and pages like any other outage.

For an ad-hoc look at a certificate’s chain and hostname match without creating a monitor, use the free SSL checker.

How the alerts fire and clear

Both checks feed the normal monitor alert path described in Alerts:

1. A check returns a failure (“domain example.com expires in 21 days (threshold: 30 days)”).
2. After the monitor’s failure threshold of consecutive failures (default 3), the monitor turns Critical and an alert is created.
3. The alert follows the monitor’s escalation policy - email, Slack, Telegram, WhatsApp, SMS, push to the mobile app - and the schedule and quiet-hours rules on that policy decide who is woken.
4. Repeated failing checks re-trigger the same alert (incrementing its trigger count) rather than sending a fresh page every day.
5. When a check succeeds again - the domain or certificate was renewed - the monitor recovers and the alert auto-resolves.

Note the arithmetic in step 2 for daily domain checks: three consecutive daily failures means the warning is delivered roughly three days after the lead time is crossed. Set the lead time with that margin in mind, or lower the monitor’s failure threshold.

These alerts carry the same kind as a down alert, so severity and urgency come from the escalation policy you bind, not from the check. If certificate warnings should reach a working-hours channel rather than the on-call phone, bind a policy that does that. See Escalation policies.

Creating the monitors

• Web dashboard: Monitoring -> Monitors -> Add New, type Domain Expiry, or type HTTP/HTTPS with SSL certificate monitoring enabled. The walkthrough is in Monitor a website.
• Mobile app: the Infra tab can create HTTP and domain-expiry monitors. See Mobile app.
• From an AI assistant: the MCP tools create_domain_expiry_monitor and create_https_monitor take the same fields. See AI assistants.
• API: POST /api/v1/monitors/create with type: "domain" or type: "http". See the API reference.