How to set up domain monitoring alerts

A domain expiring while you're on vacation, or a competitor snatching a name you'd been watching manually for months, these aren't edge cases. They happen because manual tracking doesn't scale. This article explains how to configure domain monitoring alerts: which event types to cover, how to set thresholds, and what each alert actually checks. By the end, you'll have a system that runs without you.

Why calendar reminders are not enough

A calendar reminder fires on a date. RDAP data changes on its own schedule, often without warning.

The most obvious gap: calendar reminders only track expiration dates. They say nothing about status changes. A domain can be placed in clientHold (meaning its DNS stops resolving) with no communication to the owner whatsoever. A clientTransferProhibited status can be silently removed, which is often the first step in an unauthorized transfer. Nameservers can change overnight.

Consider what happens when a domain goes into clientHold unexpectedly. Your site stops loading. Your emails bounce. By the time you notice, it's been hours. If you'd had a status change alert configured, you would have seen it within the same monitoring cycle.

Manual checks (opening WHOIS every month, scanning a spreadsheet) only tell you the state at that moment. They don't tell you what changed between checks.

The events a monitoring system must cover

A useful alerting system covers more than just "domain expires soon." Here's what matters:

• Expiration approaching: configurable at 90, 30, and 7 days before expiration. Different thresholds for different domains make sense, a mission-critical production domain deserves a 90-day warning, a parked defensive domain can wait until 30.
• RDAP status change: clientTransferProhibited removed, clientHold added, pendingDelete appearing. Each of these signals a different problem and a different required action.
• Registrar or nameserver change: a sudden nameserver change is one of the clearest indicators of domain hijacking or an unauthorized transfer in progress.
• Availability: the domain you've been watching just became free to register.

RDAP statuses vs. WHOIS statuses

WHOIS output is plain text. Its format varies by registrar, some use "clientTransferProhibited", others write it differently, some abbreviate it. Parsing that reliably is fragile.

RDAP returns structured JSON with status codes defined in RFC 7483. The field values are standardized across registries. That means alerts built on RDAP status changes are comparing apples to apples, not guessing at text patterns. It also means they're comparing against data from the registry itself, not a cached copy somewhere upstream.

How to configure alerts in Domain Sentinel

The setup takes under five minutes per domain:

1. Add the domain to your watchlist. Search for the domain in the lookup bar. Whether you own it or not, click "Add to watchlist." Domain Sentinel starts monitoring it from that point.
2. Select the events to monitor. For each domain, choose which alert types to activate: expiration warnings, status changes, registrar/nameserver changes, availability.
3. Set expiration thresholds. Configure when expiration alerts fire. The default covers 30 and 7 days; you can add 90 days for critical domains.
4. Choose your notification channel. Email is available by default. For automated workflows, webhook delivery lets you pipe alerts into Slack, PagerDuty, or any system that accepts POST requests.

Per-domain threshold configuration

Not all domains deserve the same attention. A registrar managing 50 client domains doesn't need 90-day warnings on every defensive registration, just on the ones that host actual services.

Domain Sentinel lets you set different thresholds per domain. Your primary production domain might have 90/30/7 day alerts. A secondary redirect domain might only need 30 and 7. This granularity matters when you're managing a portfolio of 20 or more names: it cuts alert fatigue while keeping critical coverage in place.

What Domain Sentinel checks at each cycle

At each verification cycle, Domain Sentinel queries RDAP for every domain in your watchlist. The response is compared against the stored snapshot from the previous cycle. If any field differs (statuses, nameservers, registrar, expiration date) an event is recorded and, if you've configured an alert for that event type, a notification is sent.

The data comes from the registries directly. For .com, that's Verisign. For .fr, that's AFNIC. No intermediate cache. This matters because some third-party monitoring services maintain their own database, updated weekly or monthly, if a domain goes into pendingDelete on a Tuesday, they might not catch it until the following weekend.

False negatives are the dangerous failure mode in domain monitoring. By querying RDAP directly, Domain Sentinel minimizes them.

Case study: monitoring a portfolio of domains

Consider an agency managing 50 client domains across GoDaddy, OVH, and Namecheap. Here's what the workflow looked like before and after centralized monitoring:

	Before	After
Expiration tracking	Excel spreadsheet, updated manually	Automated, synced from RDAP
Reminder method	Email from registrar (often spam) + calendar entries	Configurable alerts per domain
Status change detection	None	Immediate alert on any RDAP change
Coverage	Expiration dates only	Expiration + status + nameservers + availability
Risk	Domains expiring unnoticed	Caught days or weeks in advance

The spreadsheet approach isn't wrong in principle, it's just operationally fragile. Any manual system fails the moment someone gets busy, changes jobs, or simply forgets to open the file.

If you manage more than three domains, manual tracking creates a real operational risk. Add them to a watchlist, configure the alerts once, and Domain Sentinel handles the rest.