BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Building Your Own Drop-Monitoring System: How to Track a Domain From Expiry to the Day It Drops
A drop-monitoring system is a small piece of software you run yourself that watches a list of domains, reads each name’s lifecycle stage from the public registry, and tells you the moment one is about to be released. The guides ranking for this subject hand you a service to pay for. This one shows you how to build the watcher.
The honest position is this. The monitoring half of the problem is genuinely buildable in an afternoon, because the data is public and the lifecycle clock is fixed by ICANN policy. The catching half, winning a high-value name in the seconds after it drops, needs registry-connected infrastructure that a homemade poller cannot match. This guide teaches the build, states plainly where it stops being enough, and never pretends a script can beat a backorder service to a contested name.
It also draws the line that matters for SEO. A monitor is a research instrument, not an acquisition strategy. When the goal is owning a domain with real inherited authority, the public drop is the slowest, least reliable path to it. SEO Domains operates the curated marketplace where aged and expired domains are screened across their backlink profiles before they are listed, so the same authority you are chasing in the drop is available as a purchase, not a race against a registry clock.
What a drop-monitoring system does, and what it cannot do
A drop-monitoring system watches a defined list of domains, queries each one’s registration status on a schedule, detects when a name moves toward deletion, and alerts you before it drops. It is a research and timing tool. It does not register the name for you, and it cannot guarantee you win a contested name at the instant of release. That second job belongs to registry-connected catching infrastructure.
Separating those two jobs at the start saves a lot of wasted effort. The guides that rank for this topic blur them together, then quietly point you at a paid service for both. The reality is cleaner when you split it.
What the monitor handles well
The monitoring layer is the part you can own outright. Every fact it needs is public: a domain’s expiry date, its current lifecycle stage, and its registry status code are all returned by a free RDAP query. So a monitor reliably does four things.
- Tracks a watchlist of names you care about, from a handful to thousands.
- Reads each name’s current lifecycle stage on a schedule you control.
- Calculates the predicted drop date from the lifecycle clock and the status codes.
- Alerts you, by email, webhook, or message, when a name enters its final window.
For research, due diligence, and portfolio renewal tracking, that is the whole job. You know which names are approaching release, and exactly when, with no subscription.
Where the monitor stops
The catching layer is a different animal. When a high-value name finally releases, it is gone in seconds, claimed by a backorder service running dozens of registry connections in parallel. WhoAPI, a registration-data provider, frames the split directly in its own write-up on the subject.
The implied second part, the catch, is the hard one. This guide builds the easy part in full, then in the monitor-versus-catch section gives the catch its honest weight so the system you build is never mistaken for a name-winning machine it is not.
The lifecycle clock your monitor watches: 45, 30, and 5 days
Your monitor watches a fixed timeline set by ICANN consensus policy. After a gTLD name expires, the registrar has up to 45 days to delete it. The registry then holds the deleted name in a 30-day Redemption Grace Period, followed by a 5-day Pending Delete, and only then releases it on a first-come, first-served basis. Those numbers are what make the drop predictable enough to monitor at all.
The reason a homemade monitor works is that this clock is not a secret. It is written into binding policy, so once a name enters the deletion path, the day it drops is a fixed arithmetic from the status codes you can read.
The three fixed numbers
Three intervals do the heavy lifting, and each comes from a named ICANN policy, not folklore.
- Up to 45 days to delete. Under ICANN’s Expired Domain Deletion Policy and the Registrar Accreditation Agreement, a registrar must delete an unrenewed gTLD name within 45 days, absent extenuating circumstances. This window is registrar-controlled, so its exact length varies.
- 30-day Redemption Grace Period. Once the registrar asks the registry to delete the name, the registry opens a roughly 30-day restore window in which the original owner can still reclaim it for a fee. ICANN describes this as the redemptionPeriod stage.
- 5-day Pending Delete. After redemption closes, the name enters a fixed 5-day Pending Delete, during which no one can register or restore it. At the end of those five days it drops.
The deeper paragraph-by-paragraph citation for each interval lives in the sibling guide. For a monitor, the practical takeaway is that the registry half of the clock, the 30 plus 5, is fixed and predictable, while the registrar half is not.
Registrar half (variable)
The auto-renew grace period and the up-to-45-day deletion window are controlled by the registrar. The exact day a name moves from expired to deleted differs registrar to registrar, so your monitor treats this stage as a range, not a date.
Registry half (fixed)
Once the name shows redemptionPeriod, then pendingDelete, the registry clock is fixed: roughly 30 days plus 5 days. From the day pendingDelete appears, the drop is five days out. This is the precise window your monitor exists to surface.
The data sources: RDAP, WHOIS, drop lists, and registrar APIs
A monitor needs two kinds of input: a source of candidate names to watch, and a source of live lifecycle status for each name. For status, RDAP is the modern, structured, machine-readable choice that replaced WHOIS as the ICANN standard on 28 January 2025. For candidate names, public drop lists and zone-based expiry feeds populate the watchlist. Registrar APIs belong to the catch layer, not the monitor.
Picking the right source for each job is the bulk of the design. The competing guides lean on WHOIS scraping, which is now the legacy option. Starting from RDAP makes the whole build cleaner.
RDAP: the status source to build on
RDAP, the Registration Data Access Protocol, is the successor to WHOIS. ICANN sunset legacy WHOIS for gTLDs on 28 January 2025, making RDAP the authoritative source for registration data. It was developed by the IETF and has been offered by accredited registrars since 2019. The practical advantage for a builder is the format: an RDAP request goes out over HTTPS and the response comes back as structured JSON, including an array of status values such as redemptionPeriod and pendingDelete. No fragile text parsing, no per-registrar template guessing.
WHOIS: the fallback, not the foundation
WHOIS still answers for a handful of legacy ccTLDs and edge cases that have not fully migrated. Treat it as a fallback your monitor falls through to only when an RDAP endpoint is unavailable for a given name. Building primarily on WHOIS, as the field’s current how-to guides do, means inheriting its formatting inconsistency and privacy-masking problems as your default instead of your exception.
Candidate sources: how names enter the watchlist
The status source tells you where a name is in its life. A separate source supplies the names in the first place. Three populate a watchlist.
- Your own list. Names you already track, from a research shortlist, a portfolio, or a competitor’s expiring assets.
- Public drop and expiry feeds. Aggregators such as ExpiredDomains.net publish names approaching deletion that you can seed a watchlist from.
- Registry drop lists. A registry that publishes the names scheduled to drop gives the highest-precision candidate source for the fixed-window stage.
Registrar APIs belong to the catch, not the monitor
Practitioners on the NamePros forum building drop-catching software converge on the same registrar APIs, Dynadot, Namecheap, NameSilo, and GoDaddy among them, as the integration that places the actual registration attempt. That is the catch layer. A monitor does not need any of them. Keeping registrar APIs out of the monitor keeps the build simple and the credentials surface small.
| Source | What it provides | Layer |
|---|---|---|
| RDAP | Live lifecycle status as structured JSON: redemptionPeriod, pendingDelete, expiry date | Monitor (primary) |
| WHOIS | Same data as free text, for legacy names RDAP does not yet cover | Monitor (fallback) |
| Public drop and expiry feeds | Candidate names approaching deletion to seed the watchlist | Monitor (candidates) |
| Registry drop lists | Names scheduled to drop, the highest-precision candidate feed | Monitor (candidates) |
| Registrar APIs | The registration attempt itself at the moment of release | Catch (not the monitor) |
The architecture: the five components of a self-built monitor
A self-built drop monitor is five small components: a watchlist store that holds the names to track, a poller that queries RDAP on a schedule, a status parser that reads the lifecycle stage and computes the predicted drop date, an alerter that fires when a name enters its final window, and a state store that remembers what was already seen so alerts do not repeat. Each is simple alone, and the simplicity is the point.
Keeping the design to five parts means each one is independently testable and replaceable. The architecture below is the skeleton the step-by-step build fills in.
The five components
- Watchlist store. A list of names plus optional metadata, such as why each name is being tracked. A flat file or a small database table both work.
- Poller. The scheduled job that, for each watched name, sends an RDAP request and retrieves the current status. This is the only network-facing part.
- Status parser. The logic that reads the returned status array, identifies the lifecycle stage, and where the stage is redemptionPeriod or pendingDelete, computes the predicted drop date from the fixed clock.
- Alerter. The notifier that sends a message when a name first enters its final window, by email, webhook, or chat integration.
- State store. A record of each name’s last-seen status, so a name already alerted on is not alerted on again every poll.
| Component | Job | Simplest implementation |
|---|---|---|
| Watchlist store | Holds the names to track | A text file or one database table |
| Poller | Queries RDAP on a schedule | A script triggered by cron |
| Status parser | Reads the stage, computes the drop date | A function over the RDAP status array |
| Alerter | Notifies when a name enters its final window | An email or webhook call |
| State store | Prevents repeat alerts | A last-seen-status column or key |
Build it step by step: a seven-stage walkthrough
The build runs in seven stages: define the watchlist, choose the RDAP endpoint, write the poll, parse the status and compute the drop date, store state to dedupe, schedule the poll with cron, and wire up the alert. Each stage names the done-right move and the specific mistake that breaks a homemade monitor. This is the assembly order for the five components above.
Work through them in sequence. Each stage produces a working piece you can test before moving on, so a failure is always localised to the stage you just built.
-
Define the watchlist
Start with the names you genuinely care about, seeded from a research shortlist or a public expiry feed. Store each name with a note on why it is tracked, so the alert later carries context. Keep the list small while building; scale it once the pipeline works end to end.
The mistake: seeding thousands of names before a single poll works. A bloated watchlist multiplies every bug and runs you into rate limits before the logic is proven.
-
Choose the RDAP endpoint
RDAP queries route through the IANA RDAP bootstrap service, which maps each TLD to its authoritative RDAP server, so your poller resolves the right endpoint per name instead of hardcoding one. This is the read-only, public source the monitor is built on, with WHOIS reserved only as a fallback for names RDAP does not yet serve.
The mistake: hardcoding one registry’s RDAP URL for every TLD. A .com name and a .io name resolve to different servers, so a single hardcoded endpoint silently returns nothing for the bulk of your list.
-
Write the poll
For each name, send one HTTPS RDAP request and capture the JSON response. Handle the three outcomes explicitly: a successful record, a not-found response, which for a watched name can mean it has already dropped, and an error or timeout, which must be retried instead of treated as a drop.
The mistake: treating any non-200 response as available. A timeout or a rate-limit block is not a drop. Reading it as one fires a false alert and sends you chasing a name that never released.
-
Parse the status and compute the drop date
Read the status array from the RDAP record. If it contains pendingDelete, the name drops in roughly five days, so compute and store that date. If it contains redemptionPeriod, the name is roughly 30 days plus 5 from release. This is the core value the monitor produces: a predicted drop date, not just a raw status.
The mistake: alerting on the raw status with no date math. A status code alone forces you to do the arithmetic by hand every time. Computing the predicted drop date is the whole reason to build the parser.
-
Store state to dedupe
Record each name’s last-seen status and the date it was first alerted on. On every poll, compare the new status to the stored one and act only on a transition, such as a name newly entering pendingDelete. This is what turns a noisy script into a usable monitor.
The mistake: alerting on the current status every run. Without stored state, a name sitting in pendingDelete for five days generates a fresh alert on every poll, and real signals drown in the repetition.
-
Schedule the poll with cron
Match the poll cadence to the stage. Names in the slow registrar half need checking once a day, no more. Names in pendingDelete, inside the fixed five-day window, justify a tighter cadence as the drop date approaches. A scheduled job, such as a cron entry, runs the poller unattended at the interval you set.
The mistake: polling every name every minute. Hammering RDAP servers at high frequency earns rate limits or blocks, and a name changes stage on a scale of days, so a one-minute cadence buys nothing but throttling.
-
Wire up the alert
On a real transition into the final window, send one alert carrying the name, its stage, the predicted drop date, and the tracking note from stage one. Email, a webhook, or a chat message all work. The alert is the monitor’s only output, so make it carry everything a decision needs.
The mistake: a bare alert that says only “status changed.” An alert with no predicted drop date and no context makes you re-query by hand, defeating the point of the system.
Reading the signal: EPP status codes and the drop window
The signal your monitor reads is the EPP status code returned in the RDAP record. These ICANN-documented codes report exactly where a name sits in its lifecycle. The three that matter for a drop monitor are autoRenewPeriod, redemptionPeriod, and pendingDelete. When a name shows pendingDelete, its release is a fixed five days away, which is the single highest-confidence read your monitor produces.
EPP, the Extensible Provisioning Protocol, is the language registrars and registries use to manage domains. Its status codes are the vocabulary your parser interprets, and ICANN publishes the full list with plain-language explanations.
The three codes a drop monitor cares about
A name passes through a range of status codes across its life, but a drop monitor narrows its attention to three transitions on the deletion path.
- autoRenewPeriod. A temporary grace status after an expired name is auto-renewed by the registry. Its presence signals the registrar half of the clock, where the timeline is still variable.
- redemptionPeriod. The registrar has asked the registry to delete the name, opening the roughly 30-day window in which the original owner can still restore it for a fee. The name is on the deletion path, but not yet certain to drop.
- pendingDelete. Redemption has closed. The name is locked for a fixed five days and then drops. No one can register or restore it during this window. This is the highest-confidence read your monitor can return.
| Status code | What it means | What the monitor does |
|---|---|---|
| autoRenewPeriod | Expired name auto-renewed by the registry, a temporary grace status | Watch on a slow cadence; timeline still variable |
| redemptionPeriod | Registrar asked the registry to delete; ~30-day owner restore window open | Flag as on the deletion path; predicted drop ~35 days out |
| pendingDelete | Redemption closed; name locked for a fixed 5 days, then drops | Alert now; compute the exact drop date five days out |
| ok / active | Name registered and outside the deletion path | No action; keep on the watchlist |
One caution belongs here. The same status codes also exist in client and server variants, where a server code set by the registry takes precedence over a client code set by the registrar. For a deletion-path monitor this rarely matters, because the redemptionPeriod and pendingDelete stages are registry-driven, but a robust parser reads the full status array instead of the first code it finds.
The monitor versus the catch: where a homemade system stops
Done well, a homemade monitor is a precise, free research instrument that tells you exactly when names release. Done as an acquisition strategy, it fails, because watching a drop and winning a drop are different problems. The catch needs dozens of registry connections firing in parallel in the milliseconds after release, infrastructure that backorder services run and a single script cannot replicate. The honest verdict is to build the monitor for what it is good at, and to be clear-eyed about what it is not.
This is the neutral reality the vendor guides avoid, because their answer to both halves is the same paid product. Split the verdict and it becomes useful.
Why the monitor is genuinely worth building
For research, the monitor is the right tool and costs nothing but the time to build it. It answers a real question, which names are approaching release and when, without a subscription or a per-query fee. It is also a clean way to learn the lifecycle in depth, because you are reading the live status codes directly, not trusting a dashboard’s summary.
Why the catch is a different, harder problem
The catch is where the homemade system meets its limit. When a sought-after name drops, the release is a first-come, first-served scramble measured in seconds. Drop-catching services win those races by maintaining dozens of concurrent registrar and registry connections that submit the registration the instant the name frees. A single poller, however well built, sends one request at human-scale timing and loses the contested names every time. The NamePros practitioners who build this software for a living describe it as needing queueing systems, scheduling algorithms, proxy networks, and registrar API integration, an infrastructure project, not a script.
The honest build-versus-buy read
Neither choice is the right one for everyone, and the decision is yours. Build the monitor when the goal is research, timing intelligence, or learning the lifecycle, where a free, owned tool is genuinely the best fit. Use a backorder service when the goal is winning a specific contested name at the public drop, where the parallel infrastructure is the only thing that competes. And when the goal underneath both is owning a domain with real inherited authority, the drop is seldom the efficient path at all. A screened name acquired directly delivers the same authority without the race, which is the sourcing route the next section returns to. To browse vetted aged and expired domains instead of building the catch layer, the SEO Domains marketplace lists names already screened across their backlink profiles.
Common drop-monitor mistakes: the build checklist
The mistakes that break a homemade monitor are a short, repeatable list, and each has a documented fix. They cluster around three failure modes: misreading the data source, mishandling status, and polling carelessly. Use this table as the scannable reference while you build, so the monitor you ship is the reliable version, not the noisy one.
The table consolidates the per-stage mistakes from the build walkthrough into one place. The left column is the mistake, the centre column is why it breaks the monitor, and the right column is the fix.
| The mistake | Why it breaks the monitor | The fix |
|---|---|---|
| Building primarily on WHOIS scraping | Free-text formatting varies by registrar and breaks the parser constantly | Build on RDAP’s structured JSON; keep WHOIS as a fallback only |
| Hardcoding one RDAP endpoint | Different TLDs resolve to different servers, so the bulk of names return nothing | Resolve the endpoint per TLD via the IANA RDAP bootstrap |
| Treating any non-200 as available | A timeout or rate-limit block fires a false drop alert | Handle not-found, error, and timeout as separate outcomes; retry errors |
| Alerting on raw status with no date math | A status code alone forces manual arithmetic every time | Compute and store the predicted drop date in the parser |
| No stored state | A name in pendingDelete re-alerts on every poll for five days | Store last-seen status and alert only on a real transition |
| Polling every name every minute | High-frequency polling earns rate limits, and stages change over days | Match cadence to stage: slow for the variable half, tighter near the drop |
| Reading only the first status code | Client and server codes coexist; the wrong one misreads the stage | Parse the full status array; let the registry server code take precedence |
| Ignoring the timezone of the drop | A drop date computed in the wrong zone is off by hours at the critical moment | Normalise all lifecycle dates to UTC end to end |
| Mistaking the monitor for a catcher | A single poller cannot win a contested name at release | Use the monitor for research; source contested authority a calmer way |
Drop-monitoring frequently asked questions
The questions researchers and domain investors raise when they set out to build a drop monitor, answered against the lifecycle policy record and the monitor-versus-catch distinction this guide draws.
Q1Can a homemade drop monitor really catch a domain when it drops?
No, and conflating the two is the commonest error. A monitor tells you when a name is about to release; it does not register the name for you. Winning a contested name at the instant of release is a first-come, first-served race that backorder services win with dozens of parallel registry connections. A single poller is a research tool, not a catcher.
Q2Is RDAP or WHOIS the right source for the monitor?
RDAP, as the primary source. ICANN sunset legacy WHOIS for gTLDs on 28 January 2025, making RDAP the authoritative lookup, and its structured JSON responses are far easier to parse than WHOIS free text. Keep WHOIS only as a fallback for legacy ccTLDs and names RDAP does not yet serve.
Q3What poll cadence does a drop monitor need?
Match the cadence to the lifecycle stage instead of polling everything constantly. Names in the variable registrar half change over days, so once daily is enough. Names in pendingDelete, inside the fixed five-day window, justify a tighter cadence as the drop date nears. Polling every name every minute earns rate limits and buys nothing, because stages move on the scale of days.
Q4How does the monitor predict the exact drop date?
From the status code and the fixed registry clock. When a name shows pendingDelete, it drops in a fixed five days, so the date is simple arithmetic. When it shows redemptionPeriod, release is roughly 30 days plus 5 away. The registrar half of the clock, up to 45 days to deletion, is variable, so a precise date is only computable once the name reaches the registry-controlled stages.
Q5Is building a monitor worth it if I just want an aged domain with authority?
Build it for research and timing intelligence, where a free owned tool is the best fit. But if the underlying goal is owning a domain with real inherited authority, the public drop is the slowest, least reliable path to it. A screened aged or expired domain acquired directly delivers the same authority without the race against the registry clock, which is why sourcing from a vetted catalogue is the calmer route for that goal.
From monitor to acquisition: the calmer path to the same domain
A drop monitor is the right tool for research and timing, and a poor one for acquiring authority. The public drop is a race, and the same inherited authority a researcher chases there is available as a screened purchase. Sourcing a vetted aged or expired domain delivers the backlink profile without the clock, the parallel infrastructure, or the gamble. SEO Domains operates the curated marketplace where that raw material is read before it is listed.
What the monitor was really for
Step back from the build and the goal underneath it is usually not the monitor itself. It is access to a domain with real, inherited authority: a name whose existing backlink profile gives a new project a foundation an empty domain lacks. The monitor is one way to learn when such names release. It is not the only, or the surest, way to own one.
Why the drop is the slow path to authority
The public drop is the hardest route to a quality name for the same reasons the catch is hard to build. The best names are contested, won in seconds by parallel infrastructure, and a homemade monitor that surfaces the timing still cannot win the race it surfaces. The authority you wanted is real, but the drop is a bottleneck, not a doorway.
Source the authority directly, screened before listing
The legitimate demand behind building a drop monitor is access to real domain authority you can own. That is the product, not a monitoring tool and not a catching service. SEO Domains operates the curated marketplace where aged and expired domains are screened across their backlink profiles and authority metrics before they are listed and priced, so the name arrives vetted, not caught on a clock.
