Domain Watchdog is a self-hosted web application for keeping an eye on domain names you care about. It collects publicly available registration data over RDAP, stores each domain’s history, and shows you how its registration status changes over time — including the moment an expiring domain drops back into the open so you can register it yourself.

What it does

• Historical tracking — every lookup is stored, so you can follow a domain from its creation through renewals and ownership changes instead of seeing a single, current-day snapshot.
• Domain report — registration lifecycle (Registration, Active, Auto-Renew Grace Period, Redemption Grace Period, Pending Delete), registry and registrar locks, DNSSEC state and the published EPP status codes for the name.
• Entity graph — the registrar, registry and nameservers behind a domain are drawn as a relationship diagram, which makes it obvious who actually controls the name.
• Watchlists and a tracking table — group the domains you are following, get a per-domain view of upcoming expirations, and share a watchlist through an API token.
• Backorder and auto-purchase — connectors for registrar APIs let Domain Watchdog detect the deletion of a watched name and place the order for you, so you are not refreshing a WHOIS page at the right minute.
• API and RSS — a REST API with JWT authentication plus RSS feeds for events and status changes, for wiring the data into your own dashboards.

Why RDAP instead of WHOIS

RDAP returns structured JSON rather than free-form text, so registration events, status codes and entities can be parsed reliably and diffed between lookups. Domain Watchdog caches aggressively and rate-limits its RDAP requests so a large watchlist does not turn into a flood of queries against registries.

Running it

The project ships as a Docker image and documents a Docker Compose deployment. A complete instance needs three pieces: the application container (which serves the web UI and API through its own web server), a PostgreSQL database for the collected data, and Valkey for cache, locks and the message queues that drive RDAP polling. In the reference Compose file a separate worker container consumes those queues, so the application and the worker should be treated as a pair. The container is served over HTTP by default; enable secure cookies once it sits behind TLS. A single domain’s first report appears after the worker has processed the queued lookup, which typically takes a few seconds.

Who it is for

Self-hosters and small teams who keep an eye on brand or project domains and want their own history and alerting rather than a paid domain-monitoring subscription. Because every RDAP call leaves your instance, the deployment should be able to reach the registries directly; a deployment that cannot reach RDAP will show a domain as unsupported rather than inventing data.