Domain expiry monitoring: catch it before the outage

Domain expiry monitoring: catch it before the outage

5 min read

Domain expiry monitoring is an automated check that reads your domain's registration record (WHOIS or RDAP) on a schedule and alerts you weeks before the expiration date, so a missed renewal never quietly takes your website, email, and TLS certificates down at the same time.

A lapsed domain is one of the strangest outages to debug, because nothing you own breaks first. Your servers stay healthy. Your code is fine. The registry simply stops answering for your name, and the website stops resolving, email starts bouncing, and certificate renewal for that name fails. The fix is a single renewal payment. The hard part is noticing in time, since no alarm inside your own infrastructure ever fires.

What actually happens when a domain expires

Two beliefs cause most of the damage: that an expired domain is gone instantly, and that it becomes available to buy the moment it lapses. Neither is true. A generic top-level domain (.com, .net, .org and similar) moves through a fixed set of phases after its expiry date, and the timing is set by ICANN policy, not by your registrar.

Phase Typical length Does the name resolve? How you recover
Active until the expiry date yes renew anytime, normal price
Auto-renew grace up to 45 days (registrar-dependent) usually, until the registrar pulls it renew at the normal price
Redemption (RGP) 30 days no, removed from DNS restore through your registrar and pay a restore fee
Pending delete 5 days no nothing, the name cannot be restored
Released first-come basis no anyone can register it

The redemption and pending-delete windows are set by ICANN policy, and a registrar cannot shorten them. ICANN states it plainly in its renewal and expiration FAQ for registrants: "the domain name will enter into a redemption period for 30 days, under which it remains available to restore. If it is not restored, the domain name will enter into PendingDelete status for 5 days." After that it drops. The one variable piece is the auto-renew grace window before redemption: ICANN's gTLD lifecycle allows up to 45 days there, and each registrar picks its own length inside that cap.

The trap is the auto-renew grace period at the top. The site often keeps resolving for days or weeks after the expiry date, so nobody notices anything is wrong. The clock only becomes visible when the name falls into redemption, resolution stops, and now recovery means a restore fee instead of a routine renewal. By then the outage is already live.

Why "auto-renew is on" is not enough

Auto-renew is a payment instruction, not a guarantee. It is the single most common reason teams believe a domain is safe when it is not. Here are the ways it fails silently:

  • The card on file expired or was declined. The auto-renew attempt fails and the only record of it is an email receipt that never arrives.
  • The renewal notices go to an address nobody reads: a founder who left, a generic role inbox, an alias that forwards into a void.
  • The domain is locked over a billing dispute or compliance hold, so the renewal cannot complete even though a card is on file.
  • Ownership drifted. A contractor registered it on a personal account, or an acquisition left the paying party without visibility into the registrar.
  • The registrar dashboard shows one date and the registry shows another.

That last one is worth seeing directly. The authoritative expiry date lives at the registry, and even the public record warns you not to trust a copy of it. Run a lookup against any domain and you will find this notice attached:

"The expiration date displayed in this record is the date the registrar's sponsorship of the domain name registration in the registry is currently set to expire. This date does not necessarily reflect the expiration date of the domain name registrant's agreement with the sponsoring registrar."

Monitoring sidesteps all of this by watching the registry answer on a schedule, which is the one source of truth no billing setting can quietly contradict.

How to check a domain's expiry yourself

You do not need a tool to read the expiry date once. The classic way is whois, which queries the registry over port 43 and returns a flat text record. Filter it down to the lines that matter:

whois example.com | grep -iE 'expir|status|registrar:'
   Registrar: RESERVED-Internet Assigned Numbers Authority
   Registry Expiry Date: 2026-08-13T04:00:00Z
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited

The line you want is Registry Expiry Date. The Domain Status lines are the EPP status codes, and each one links to its definition in ICANN's code namespace. Two are worth knowing for expiry: autoRenewPeriod tells you the name is sitting in the grace window after lapsing, and redemptionPeriod or pendingDelete mean the recovery clock has already started.

WHOIS is being replaced by RDAP, which returns the same facts as structured JSON instead of registrar-specific text. It is easier to parse and the field names are consistent across gTLDs:

curl -s -H "Accept: application/rdap+json" \
  https://rdap.verisign.com/com/v1/domain/example.com
"events": [
  { "eventAction": "registration",  "eventDate": "1995-08-14T04:00:00Z" },
  { "eventAction": "expiration",    "eventDate": "2026-08-13T04:00:00Z" },
  { "eventAction": "last changed",  "eventDate": "2026-01-16T18:26:50Z" }
]

The expiration event is your date. Reading it once is trivial. The reason this turns into a monitoring problem rather than a calendar reminder is the friction around doing it reliably, forever:

  • WHOIS text format varies by registrar and TLD, so a parser that works for .com breaks on the next extension.
  • Both WHOIS and RDAP enforce rate limits, so polling a portfolio naively gets you throttled.
  • Many country-code registries (a number of European ones, for example) restrict or omit expiry data in public records, so coverage is never universal and you have to know where the gaps are.
  • Since registration data went largely redacted after GDPR, tooling that keyed off registrant or contact fields broke, though the expiry date itself usually stays visible.

Alerts that actually fire in time

A single reminder 30 days out is the default, and it is the wrong design. One email is one chance to be missed. The point of monitoring is repetition and escalation, so treat the warning as a ramp rather than a single event:

  1. Stagger reminders across a ramp instead of firing once. Something like 60, 30, 14, 7, and 1 days out, with rising urgency, gives the message several chances to reach a human who can act.
  2. Route it where incidents go, not just to email. The same channel your on-call already watches beats an inbox rule nobody maintains.
  3. Watch domains you depend on but do not own. You cannot renew a vendor's API domain or your email provider's domain, but knowing it is about to lapse tells you why your integration is about to break.

There is one failure mode that catches even careful teams: the alert depends on the thing that is expiring. If your monitoring emails you at an address on the same domain that is about to lapse, the warning vanishes exactly when you need it. Send expiry alerts through an out-of-band channel, on a domain or service that is not the one being watched.

Monitoring has an honest limit worth stating: it warns you, it does not pay for you. It buys time and removes the surprise, but someone still has to click renew. What it kills is the silent failure, the case where the first signal you get is a customer asking why the site is down.

Where this fits with WebPixie

WebPixie's domain monitoring runs the daily WHOIS or RDAP lookup for you across more than 1,000 TLDs using the IANA database, sends escalating expiry alerts as the date approaches, and flags registrar, nameserver, and status-flag changes along the way. An approaching expiry can open an incident automatically, so it lands in the same place as the rest of your reliability signals instead of a forgotten reminder.

A domain, its DNS, and its TLS certificate are three separate clocks, and each one can stop on its own without warning from the others. The same discipline applies to certificates, which expire on a schedule of their own: see how to check SSL certificate expiration for the certificate side of the same problem.

← Back to blog