The first time it happens to a client of yours, you'll get a Slack message at 11:47 on a Saturday that just says "is acme.com supposed to redirect to GoDaddy?" — and the answer is no, but the registrar parked the domain twelve hours ago because the auto-renewal failed and nobody noticed.
This is a different problem from SSL silently expiring. SSL fails fast and visibly — browsers throw a big interstitial. Domain expiry is slower and meaner: there's a 30-day grace period in most TLDs where the domain is suspended and shows a registrar parking page, but recoverable; then a 30-day redemption period where you can still get it back but for $80–$200 in fees; then it drops to public release and a domain squatter buys it for $9 and your client is now negotiating to buy back their own brand for four figures.
Auto-renewal is supposed to make all of this disappear. It mostly does. The "mostly" is what this post is about.
How registrars actually do auto-renewal
Three things have to be true on the renewal date for the domain to renew without you noticing:
- The auto-renew flag is set on the domain.
- There's a payment method on file at the registrar.
- The payment method works when charged.
If any of these fails the registrar emails the account holder and waits. The grace period is 30 days for most generic TLDs (.com, .net, .org). For ccTLDs it varies — .io and .co are also 30, .ai is 10, .uk is 30 but the domain stops resolving on day 1.
Now the seven specific reasons we keep seeing.
1. The card on file expired
Most common by a long way. Whoever set up the domain registration in 2022 used their personal card. The card expired in 2024. Auto-renewal billing fails on the renewal date in 2026.
The registrar emails. The email goes to domains@oldagencyname.com — an inbox nobody reads anymore because the agency rebranded.
Detection: this is invisible from outside the registrar. You can't see "did the renewal succeed" via WHOIS. What you can see is the WHOIS expiry date — if it doesn't move forward on the expected day, that's your signal.
# Check the expiry date on a domain (RDAP, the modern WHOIS):
curl -s -H "Accept: application/rdap+json" \
https://rdap.verisign.com/com/v1/domain/acme.com \
| jq '.events[] | select(.eventAction=="expiration") | .eventDate'
Good monitoring fires at 30, 14, and 7 days out — that's enough headroom to chase the client about an expired card without it becoming a crisis.
2. The card is fine but billing details don't match
Happens with B2B clients. The card on file is a corporate card with strict address verification. The registrar charges from an IP geo that doesn't match. The bank rejects it as suspicious.
Detection: same as #1 — watch the WHOIS expiry date. The signal is identical: it doesn't move forward. The fix is different — the client has to talk to their finance team to whitelist the registrar charge.
Catching this early matters because corporate finance teams take days, not hours, to respond.
3. Auto-renew was turned off
Sometimes deliberately, often by accident. A client logs into Namecheap, browses around, sees a "save money" prompt, clicks it. Auto-renew off, domain renews manually next year. Manually meaning never.
Detection: WHOIS-side this looks identical to a working renewal until the day expiry hits. Some registrars expose clientUpdateProhibited or autoRenewPeriod in WHOIS — but most don't, and what's exposed varies by registrar.
The pragmatic check: alert at 30 days regardless. If the renewal succeeds at day 25, the alert clears. If it doesn't, you have time to ask the client whether auto-renew is on.
4. Registrar lock conflicts
If the domain has a registrar lock (which it should, for security), some registrars require the lock to be temporarily released for the renewal transaction. If your client uses a third-party DNS host or has WHOIS privacy enabled with a partner provider, sometimes the unlock-renew-relock dance fails partway through.
The renewal email from the registrar says something like "Renewal pending: please confirm domain status." It's not particularly clear, and clients ignore it.
Detection: again, expiry date. We're noticing a theme.
5. The domain is held for compliance review
ICANN can flag any domain whose registrant contact info appears stale. This was rare before the GDPR shake-up; it's now common. The registrar emails asking to verify the registrant. If the registrant doesn't click the link in 15 days, the registrar suspends the domain before the expiry date.
This one is genuinely silent — there's no expiry-date signal because expiry hasn't been reached. The domain just stops resolving.
Detection: HTTP and DNS checks will catch this within 24 hours. SSL checks will catch it within hours (the cert is still valid but getaddrinfo ENOTFOUND makes the handshake impossible). What you need is monitoring that runs daily and alerts on a transition from reachable to not-reachable.
# Quick reachability probe:
dig +short A acme.com
# returns: (empty) — domain isn't resolving anymore
6. The domain was transferred mid-cycle and the new registrar didn't pick up renewal
Client moves their portfolio from registrar A to registrar B. Transfer completes successfully. But the renewal that was queued at registrar A doesn't carry over, and registrar B's auto-renew defaults to off for transferred-in domains during the first cycle.
We've seen this with all of: Squarespace → Cloudflare, GoDaddy → Namecheap, Bluehost → anything. It's a category of bug, not a registrar-specific one.
Detection: when a transfer happens, the WHOIS lastChanged event fires. If you tag domains in your monitoring with their registrar, an unexpected registrar change is itself an alert worth sending. We don't surface this as a separate alert in Pleenx yet — but we're noting it down because three of our trial users hit it.
7. The TLD itself is being deprecated
This happens. ICANN-mandated .support registrar shutdown forced everyone off .support domains in 2023. Some smaller ccTLDs have been pulled by their governments. If your client is on an exotic TLD, monitor for ICANN announcements about it.
The signal here is loud — registrars email everyone, news travels — but agencies typically only own a few domains per exotic TLD, so it falls into a personal-attention bucket rather than an automation one.
What good monitoring looks like
A useful auto-renewal monitor needs four properties:
- Daily checks, not weekly. The grace-period fees compound by the day in some TLDs.
- Three thresholds on the WHOIS expiry: 30 days (info), 14 days (warn), 7 days (critical). Below 7 days is a phone call, not an email.
- Reachability divergence detection for case 5 (compliance suspension) — watch for domains that go from "resolving" to "not resolving" while WHOIS still shows the domain as registered.
- Registrar tagging so case 6 (mid-cycle transfer) generates a soft alert.
If you don't already have something doing all four — that's what we built Pleenx for. It probes externally, no agents, no client credentials, and the alert thresholds above are exactly the defaults.
What to do tonight
If you have client domains under management and you don't know when the next renewal hits, run this on each one:
for domain in acme.com client2.com client3.com; do
echo -n "$domain: "
curl -s -H "Accept: application/rdap+json" \
"https://rdap.verisign.com/com/v1/domain/$domain" \
| jq -r '.events[] | select(.eventAction=="expiration") | .eventDate' \
2>/dev/null || echo "n/a"
done
Anything within 30 days, message the client now. Anything within 7, call them tomorrow morning.
The domains you don't have to think about because they're auto-renewing fine — those are the ones you'll find out about at 11:47 on a Saturday. Catch them before that.
Related reads: What breaks when an SSL cert expires covers the same playbook for SSL — different failure modes, similar detection strategy. If you manage WordPress care plans, the 2026 monitoring checklist is worth a skim.