Domain Expiration Monitoring: How to Never Lose a Domain to a Missed Renewal

An expired domain takes down more than any server outage. Your website, email, API, single sign-on and payment webhooks all depend on the name, and all of them stop working even though nothing in your infrastructure is broken. Unlike a crash, you can't fix it with a restart. With domain expiration monitoring in place, you see a due renewal coming weeks in advance and have time to sort out payment details, ownership or the registrar account.

In this article we explain what technically happens when a domain expires, why renewals fail even with auto-renew switched on, how to look up an expiration date yourself with RDAP, and what reliable monitoring needs to cover.

What happens when a domain expires

You don't own a domain outright; you rent it for a set period. The registry, the organization that runs a top-level domain such as .com or .eu, keeps an expiration date for every domain. You renew through your registrar, the company you registered the domain with.

What happens after the expiration date depends on the TLD and the registrar. For generic TLDs such as .com, .net and .org, the sequence usually looks like this:

1. The domain expires. Many registrars point DNS to a parking page shortly afterwards. Your website disappears, and email to your addresses stops arriving because the MX records are gone.
2. Renewal is still possible. During this grace period you can usually renew at the normal price. The registrar decides how long it lasts.
3. The domain is deleted and enters the redemption grace period. For .com this phase lasts 30 days. The domain can only be restored through the registrar, and restoring it usually costs considerably more than a normal renewal.
4. Pending delete. Five more days follow during which nothing can be done. After that, the domain is released and anyone can register it.

That last step is the dangerous one. Established domains with backlinks and search rankings are watched closely, and they are often re-registered within seconds of being released. Whoever owns the domain next can receive email sent to your old addresses, trigger password resets on services still tied to those addresses, and publish content under your name.

For generic TLDs, ICANN's Expired Registration Recovery Policy also requires registrars to send reminders before and after expiration. Country-code TLDs such as .de, .uk or .eu follow their own registry's rules.

Why domains expire despite auto-renew

Most registrars renew domains automatically. Domains still expire, and the reasons are much like those behind expired SSL certificates: the automation fails silently.

• The payment fails. The card on file has expired, was blocked after a fraud alert, or belongs to someone who has left the company. Auto-renew tries, fails and sends an email about it.
• The reminder goes nowhere. The contact address at the registrar is outdated, ends up in spam or, worst of all, sits on the very domain that is about to expire. Once the domain is gone, the warnings stop arriving too.
• Auto-renew was never on. Some registrars switch it off by default after a transfer or for certain TLDs.
• Nobody feels responsible. A previous agency, a freelancer or the founder registered the domain years ago on a personal account that nobody can log in to today.
• The client holds the domain. Agencies often run websites on domains their clients manage themselves. When the domain lapses there, the site goes down and the agency hears about it first from annoyed visitors.
• Forgotten domains. Campaign domains, typo domains and old brand names redirect to the main site. Hardly anyone looks at them until one belongs to a stranger.

In every case the server is up, the application is healthy, and the problem sits with a provider your regular monitoring never looks at.

How to check a domain's expiration date: WHOIS and RDAP

You can see the expiration date in your registrar's dashboard. For domains on other accounts, for many domains at once, or for scripts, you need a public lookup.

For a long time WHOIS was the tool for this. It returns unstructured text, though, and the format differs from registry to registry. Its successor is RDAP, the Registration Data Access Protocol. RDAP answers over HTTPS with JSON and is now the official route for generic TLDs: in January 2025 ICANN ended the requirement to offer WHOIS for them.

IANA publishes which RDAP server is responsible for each TLD in a bootstrap file. With curl and jq you can find it like this:

curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0] | index("com")) | .[1][0]'

For .com that is https://rdap.verisign.com/com/v1/. Query the domain there and pick out the expiration event:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'

The output is a UTC timestamp such as 2027-08-13T04:00:00Z. In a script you can turn it into the number of days left:

expires=$(curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq -r '.events[] | select(.eventAction == "expiration") | .eventDate')
echo $(( ( $(date -d "$expires" +%s) - $(date +%s) ) / 86400 ))

date -d is the GNU version found on most Linux servers. On macOS, use gdate from GNU coreutils instead.

Keep two things in mind. First, always look up the registrable domain, not a host name. For shop.example.co.uk that is example.co.uk. Which part of a host name is the registrable domain is defined by the Public Suffix List. Second, not every registry publishes an expiration date.

When there is no public expiration date

Some registries simply don't publish one. Germany's .de is the best-known example: IANA's bootstrap file lists no RDAP server for it, and DENIC's WHOIS service shows no expiration date. There is no publicly visible end of term at the registry level, so whether and when a .de domain is cancelled or deleted for unpaid invoices depends on your contract with the registrar. Other registries, such as SIDN for .nl, do answer RDAP queries but leave the expiration date out.

No outside lookup helps with these domains. What remains is checking your registrar account, keeping a valid payment method on file, and using a contact address that doesn't live on the domain itself. A tool that still shows an expiration date for a .de domain made it up.

What good domain expiration monitoring looks like

A one-off look at the date is no substitute for ongoing checks. In our view, reliable monitoring meets these requirements:

• The registry is the source of truth. What counts is the date the registry holds, not an entry in a spreadsheet or calendar. Only then will you notice when auto-renew has quietly failed.
• Warnings arrive early and in stages. A first warning a few weeks ahead leaves time to reach the client or dig up the registrar login. Further warnings close to the date make sure it doesn't get lost.
• Alerts don't depend on the domain itself. An alert sent to it@example.com about example.com expiring stops arriving exactly when it matters most. Slack, Telegram or an address on a different domain are better choices.
• Missing data is shown honestly. If the registry publishes no expiration date, the monitor should say so instead of staying silent or guessing.
• Temporary errors don't trigger alerts. RDAP servers rate-limit requests and are occasionally unreachable. A timeout is no reason to wake up the team.

Domain expiration monitoring complements regular website monitoring and SSL certificate monitoring. Each answers a different question: is the site reachable, is the connection trustworthy, and will we still own the name in three weeks.

A checklist for agencies and small teams

If you look after many clients, you quickly end up managing dozens of domains across several registrars. These habits have proven themselves:

1. Keep a list of every domain per client, including redirect and campaign domains. Note the registrar, the account owner and the term.
2. Put ownership in writing. Record whether the agency or the client is responsible for renewals, and who can access the registrar account in an emergency.
3. Check auto-renew and the payment method once a year, especially after a transfer or when the company card changes.
4. Use a contact address on a different domain, or a shared mailbox, so registrar reminders don't vanish along with the domain.
5. Renew important domains for several years where the registrar and TLD allow it. It doesn't replace monitoring, but it means fewer renewals that can go wrong.
6. Turn on the transfer lock if your registrar offers it for the TLD. It prevents accidental transfers; you unlock it deliberately before a transfer you actually want.

How Kaspar helps

In Kaspar, the domain registration expiry warning is on by default for every uptime monitor. We take the monitor's URL and use the Public Suffix List to work out its registrable domain. Once a day we look up the expiration date from the responsible registry via RDAP and warn you 30, 14, 7 and 1 day before by email, Slack, Telegram or Webhook. Each stage notifies you exactly once. As soon as the domain is renewed and the registry reports the new date, Kaspar closes the open warning automatically.

If a registry publishes no expiration date, as with .de, we tell you exactly that instead of inventing one. If an RDAP server is temporarily unreachable, we keep the last known state and try again the next day without alerting you. Domain expiry checks are included in every plan, alongside keyword and SSL expiry checks. You'll find all features on our home page and the plans on the pricing page.

Conclusion

An expired domain is rarely a technical problem. It is almost always an organizational one: an expired card, an outdated contact address, unclear ownership. That is exactly why an independent check pays off, one that asks the registry for the expiration date and warns you in good time. Combined with uptime checks, SSL monitoring and heartbeats for your cron jobs, you keep an eye on every place where a website can fail silently.