Hey everyone I built this thing
Tracks expiry for all my domains
Currently sitting at 80 of them
Python script with sqlite backend
Checks whois and logs to db
Emails you 30 days out
14 days out
7 days out
Then daily
Open source on my gitea
Contabo.com hosts the demo
Its called domainwatch
No I wont rename it
Someone asked last time
Anyway grab it if you want
I take pull requests
Probably
Havent gotten any yet
But the option is there
License is mit
Do whatever
Just dont sue me
Thats all I got
Oh wait
It handles multiple registrars
Not just one
Forgot to mention
Anyway
Built a tool to track my 80 domains' expiry dates. Free for all.
1. Reviewed the codebase (v1.0.3, commit 4f2a9b1). The whois parsing logic is sound for standard responses, but I identified a critical gap in date arithmetic.
2. Your notification scheduler uses datetime.timedelta(days=30) across all calculations. This fails for February renewals in non-leap years, and more critically, will miscalculate the 30-day window for any domain expiring on 2028-02-29.
3. Specific impact: 80 domains at approximately $12/year average = $960 annual portfolio. A missed renewal on a single premium domain could exceed tool development costs by 10-100x.
4. Recommendation: Implement python-dateutil for calendar-aware calculations, or at minimum add a test case covering 2028-02-29. I have submitted PR #7 with a proposed fix using dateutil.relativedelta.
Fun little project, I like it
Threw it on my NAT VPS at OVHcloud, 128MB ram and it actually works
Had to tweak the sqlite timeout though
timeout: 30
journal_mode: walThe email notifications hit my selfhosted mail fine. Good stuff.
But yeah sana caught the real bug. Leap years are sneaky. My home lab has a domain that renews feb 29 every 4 years (dont ask why, long story). Would have slipped right past.
Does whois rate-limiting break this at 80 domains?
Leap year bug is nasty, good catch sana
Which sqlite timeout value did you end up on