Domain expiry monitoring: why auto-renew and reminder emails are not enough

Domain expiry is the outage everyone believes is already handled. Auto-renew is on, the registrar sends reminders, expiry is years away - and yet expired domains keep taking down household-name services, because every layer of that default safety net fails silently and they tend to fail together. Domain expiry monitoring means one thing: a check of the registry’s own expiry date that does not depend on the registrar’s emails, the payment card, or anyone’s memory. Here is why the defaults fail, the DIY version, and the done-forever version.

The default safety net, layer by layer

Auto-renew is a payment attempt on a schedule. It fails when the card on file expires (cards outlive neither domains nor finance-team churn), when the account balance is empty, or when nobody can access the registrar account anymore. Each failure produces an email, not a renewal.

Registrar reminder emails are genuinely mandatory - ICANN requires gTLD registrars to send renewal reminders roughly a month and again about a week before expiry. But they go to the registrant address on file: a departed employee, an unmonitored alias, or an inbox on the expiring domain itself, in which case the warnings about the failure are deliverable only until the failure happens. Add spam filtering trained on years of registrar marketing mail, and delivery is a coin toss precisely when it matters.

The renewal spreadsheet - every team has one - rots at the rate the team ships. New product domain, defensive registration, the .io grabbed for a demo: none of them add themselves.

The common thread: every layer notifies the party that already failed, through a channel that may itself be down. Monitoring has to come from outside that loop.

The DIY monitor: cron plus RDAP

The honest minimum viable monitor - query each domain’s expiry over RDAP daily and warn inside a threshold:

#!/bin/bash
# /usr/local/bin/check-domains.sh
DOMAINS="example.com example.org shop-example.co.uk"
WARN_DAYS=30

for d in $DOMAINS; do
  exp=$(curl -s --max-time 15 "https://rdap.org/domain/$d" \
    | jq -r '.events[]? | select(.eventAction == "expiration") | .eventDate' | head -1)
  if [ -z "$exp" ]; then
    echo "WARNING: no expiry data for $d - check manually"
    continue
  fi
  days=$(( ($(date -d "$exp" +%s) - $(date +%s)) / 86400 ))
  if [ "$days" -le "$WARN_DAYS" ]; then
    echo "WARNING: $d expires in $days days ($exp)"
  fi
done

0 7 * * * root /usr/local/bin/check-domains.sh | mail -E -s "Domain expiry warnings" [email protected]

This works, and for a personal portfolio it may be enough. Before trusting it with anything that matters, know where it lies to you:

• Silence is ambiguous. The cron host gets rebuilt, mail breaks, rdap.org is briefly unreachable - and “no email” looks identical to “nothing due”. A monitor whose failure mode is silence needs a heartbeat on itself, at which point you are building a monitoring stack.
• Missing data reads as success. Some ccTLD registries publish no expiry date at all; without the explicit no-data branch those domains simply vanish from coverage.
• The list is the spreadsheet again. The script watches exactly the domains someone remembered to add.
• It emails the same inbox that was already failing. If ops@ is unread or on a monitored-by-nobody domain, the DIY monitor inherits the exact weakness it was built to fix.

What good expiry alerting looks like

Whatever runs the check, the alerting side has three requirements:

1. Start early, escalate late. First warning at 30+ days - time to chase a declined card or a locked account calmly. Repeat and escalate as the date approaches; what happens after expiry gets more expensive by the week, so the alerts should get louder.
2. Deliver somewhere independent of the domain. Slack, Telegram, a phone - anything that keeps working when DNS and MX on the expiring domain do not.
3. Treat registry status as signal. autoRenewPeriod or renewPeriod appearing in the status list means a renewal just happened or is in grace; redemptionPeriod means the calm window is already over. A monitor that reads the registry sees this; an inbox does not.

The done-forever version

A free AlertKick domain monitor does the above out of the box: it queries the registry’s live RDAP data daily - the same source as the free domain expiry checker - and alerts on a widening schedule as expiry approaches, through the same escalation chains as everything else you monitor: email, Slack, Telegram, WhatsApp, phone, on-call rotations. SSL certificate expiry sits in the same monitor list, which is fitting, because a lapsed domain takes every certificate under it down with it.

Domain and SSL monitors are on the free plan - add your domains in a couple of minutes, keep the cron script if you enjoy owning it, and let the renewal spreadsheet retire.