TL;DR. One HTTP check on your homepage is not enough to know your site works. It cannot tell you when your domain expires, because an expired domain still returns 200 OK from a parking page. Mail dies at the same time, just as quietly, and you keep losing money while every monitor stays green. The fix is not one clever check. It is a few plain ones, starting with the two that fail on a known date: domain and TLS expiry.
Two checks green, the server behind them is down. A status check cannot tell the difference.
I keep seeing new products treat reliability as something that takes care of itself. You ship the site, you watch it load once, and you assume it will keep loading. Hosted once, up forever. That is the most expensive assumption a young team can make, because nobody is watching on the day it stops being true.
So ask one honest question. Is one HTTP check on your homepage enough to know your whole site works?
For most teams it is not. Here is a real case that shows why.
The site was gone, but it answered 200 OK
I was looking at a startup's site last week and it would not load right. Not an error, not a timeout, just the wrong page. The domain had expired two days earlier.
When a domain lapses, the registrar does not switch the site off. It points the domain at its own parking page, the "this domain may be for sale" one. That page is a normal web page. It returns 200 OK and loads fast. It stays that way for a while too, because an expired domain is not deleted the next morning.
So the monitor sees a healthy site. Green light, no alert, everyone asleep. What could be wrong?
Your domain expired. You knew the date once, on the day you bought it a year or two ago. You told yourself you would renew closer to the time, and then you forgot. The card on file lapsed, or the reminder went to an inbox you no longer read.
Now your customers cannot get in. They panic. They email to ask whether you are still in business. And they get no answer, because the mail died with the domain too.
Why the mail dies with it
The registration carries your MX records, so when it lapses, mail to every address on the domain starts bouncing. The website looks up and the inbox goes silent, and the two failures do not obviously connect. That is why the angry email never reaches you.
The front page still answers. Behind it, nothing is running.
And the meter keeps running. While the page says 200, your ads keep sending paid clicks to a parking lander, signups never arrive, and recovery is not fully in your hands. Two days down is not a rounding error either, because downtime adds up faster than the percentages suggest. Once a domain enters redemption after expiry, getting it back can cost far more than a renewal, and the registry sets the clock, not you.
The clock after expiry
For a gTLD like a .com, the sequence is roughly this:
- Grace period. The registrar parks the domain. The site is gone but the name still answers, usually for around 30 days, and a normal renewal still works.
- Redemption, 30 days. Now it really goes dark. You can still get it back, but through a restore fee that is many times the renewal price.
- Pending delete, about 5 days. Nothing you can do. At the end it drops to whoever is waiting.
ICANN's renewal and expiration FAQ and its grace period notes have the exact stages. The practical takeaway is that the first month, the one where an uptime monitor is happily reporting 200, is the cheap month. Everything after that costs money or the domain.
My own uptime check would miss it too
I build an uptime monitor, so here is the uncomfortable part. My own HTTP check would have called that dead site up too. A 200 is a 200. A status-code check cannot tell a real page from a parking page, and it should not pretend that it can.
That is the trap. One HTTP check on the homepage, the most common setup there is, is blind by design. The site answers, the code is green, and the part that pays your bills is broken behind it.
You can bolt on body matching, and it helps a bit. Assert that the response contains a string only your app renders, and a parking page fails it. But a keyword check is still guessing at the cause after the fact. The registration date is a fact you can read months in advance, so read it.
One check is not enough, set up several
So how do you avoid reading about your own outage in a customer's email? Not with one cleverer check. With a few plain ones, each watching a different way to fail. Start with the two that hand you a date instead of a surprise.
- Domain expiry. Reads the registration record and warns you weeks before the day it lapses.
- TLS certificate expiry. The same shape, a full outage with the date printed on it in advance.
Then cover the failures a homepage check never sees: a TCP check on your database port, a DNS check that reads the answer from outside your own network, and a heartbeat for the backup job that dies without a sound. The full list is in do I need an uptime monitor.
Six checks you trust beat one that only ever watches the front door.
How to set up domain expiry with an alert
Two minutes now buys you weeks of warning later. The shape is the same in any tool that supports it:
- Add a monitor and choose the Domain expiry type.
- Enter the registered domain, for example
yourbusiness.com, not a subdomain. - Set the thresholds in days. A common choice is a warning at 30 days and a critical alert at 7.
- Attach a notification channel you actually read. Telegram, Slack, PagerDuty, SMS, a webhook, or email all work. Pick the one that reaches you at night.
From then on it checks once a day, warns you when the date crosses your line, and reminds you as it gets close. No page-watching, no false green.
If you would rather not add a service for it, a cron job that runs whois and greps the expiry date will get you most of the way. The point is the date, not the tool. What you must not do is leave the only reminder in a registrar email going to a founder's old inbox.
Key takeaways
- One HTTP check on the homepage is not enough. It stays green while the domain, the certificate, DNS, or a background job is broken.
- An expired domain serves a parking page that returns 200 OK, so status-code monitors report it as healthy.
- Email dies at the same time and even more quietly, because the MX records lapse with the registration.
- You keep losing money the whole time: paid clicks to a dead page, lost signups, and a slow, costly recovery.
- Add the checks that fail on a known date first, domain and TLS expiry, then the rest.
Common questions
Why does an expired domain still return 200 OK? The registrar parks it on a lander page instead of taking it offline. The old server is gone, but the parking page is a real web page that answers normally, so a check that only reads the status code sees success.
How long before an expired domain is gone for good? You usually get a month or two. Grace period, then a 30-day redemption where the site is dark but recoverable for a fee, then a short pending-delete stage before it is released to anyone.
What else breaks when a domain expires? Your email, at the same moment and more quietly. The MX records go with the registration, so mail starts bouncing while you are still looking at a page that loads.
Is a keyword check enough instead? It catches the parking page, which is better than nothing, but only once you are already down. The expiry date is knowable months ahead. Use both if you like, but do not skip the date.
I build Uptimepage because I wanted checks like this for my own services: domain and TLS expiry, HTTP, TCP, ping and DNS, heartbeats for background jobs, and browser flows for logins, from several regions. It is AGPL-3.0 open source, so you can run it on your own server if you prefer.
Now the question I actually want answered in the comments: what is the dumbest green check you have been burned by? I have seen a health endpoint that returned 200 with a hardcoded {"status":"ok"} while the database behind it was unreachable for six hours. I suspect yours is better.
Top comments (0)