Domain expired, website down: what actually happens next

Your app worked on Friday. On Monday it is a full page of browser warning, or it is not there at all, and nothing in your code changed. Someone sends you a screenshot and you type the words on it into a search box: domain expired, website down.

Here is the part most advice on this gets wrong. Two different failures produce that morning, they run on two different clocks, and the one that sounds cheaper is the serious one. A lapsed certificate is loud, embarrassing and replaceable today. A lapsed domain is quiet at first, and if you leave it long enough your app is not down. It belongs to someone else.

Two things sit between your app and the people who use it. The domain is the lease on the shop: the name above the door and the right to keep using it. The certificate is the licence in the window saying this shop really is the one on the sign. You rent both. Both renew on a date you set once and have not looked at since.

What happens when my domain expires?

Your app goes dark, and then you are on a clock that runs in three stages.

For .com and the other generic domains the timetable comes from ICANN rather than from your registrar, so it is broadly the same wherever you bought the name.

Still yours, already off. Your registrar keeps the name renewable at the ordinary price for a window it chooses, usually a few weeks. ICANN's Expired Registration Recovery Policy requires them to break your DNS during it: for at least the last eight days the name is still renewable, it has to stop pointing anywhere. So your app goes offline well before the name goes anywhere, which is usually how the owner finds out.

Deleted, and still recoverable. When the registrar finally deletes the registration, a 30-day Redemption Grace Period begins. ICANN requires it of almost every generic registry. Only you can bring the name back during it, only through the registrar that deleted it, and you pay a restore fee on top of the renewal. ICANN does not set that fee, and it is a great deal more than a renewal.

Pending delete. About five days in which nothing you or your registrar does makes any difference. Then the name drops.

The same policy says your registrar has to write to you: twice before the registration expires, roughly a month and a week ahead, and again within five days afterwards. So if a domain of yours has ever lapsed without warning, the thing to check is not the calendar. It is which address your registrar account has on it.

Country domains run their own timetables. .io, .co.uk, .de and the rest sit outside that policy, and some of them are considerably less forgiving. If your app is on one, read your registry's own lifecycle page rather than this section.

Can someone take my domain after it expires?

Yes, once it drops, and that is what makes this different from everything else on a security report.

Every other finding is a mistake in something you own. You can go and fix it. A dropped domain leaves your ownership entirely: the name is registered to somebody else, and everything that pointed at your app points at them now. Bookmarks. The link in your welcome email. The address on the card you handed out at a conference. The password reset link you sent last week.

Names get caught quickly, too. There are businesses whose entire product is asking for a domain the second it becomes available, which is why a name with any traffic on it rarely sits unregistered for long.

You can still try to buy it back. You are negotiating with whoever got there first, at whatever price they name. A certificate that expired this morning can be replaced this morning; a domain that dropped last month may not be for sale.

Why does my website say "not secure" when it was fine yesterday?

Two different things produce that, and which one you have is written on the screen.

"Not secure" in the address bar is your browser saying the page arrived over plain HTTP, with no certificate involved at all. Your page still loads underneath it. Nothing expired. Something is serving your site without HTTPS, which is its own problem and not this one.

An expired or untrusted certificate is not a label. It is a wall. Your app is replaced by a full page: "Your connection is not private" in Chrome, "Warning: Potential Security Risk Ahead" in Firefox. Reaching your site means finding an Advanced button and clicking through a warning that says the site is unsafe. Most visitors will not.

Read the code underneath the warning before you change anything, because it says which repair you need:

That last row is worth reading before you go looking at your host. One person reporting a certificate warning can be one person's laptop.

Why an HTTPS certificate stops renewing without anything breaking

Because renewal is supposed to happen a month before the certificate matters, and a failed renewal changes nothing you can see.

Most apps built this way are served by a host that gets certificates from Let's Encrypt and renews them on your behalf. Let's Encrypt issues 90-day certificates and recommends renewing every 60 days, so the process keeping your site alive is meant to succeed with 30 days still on the clock.

To get a new one, your host has to prove to the authority that it still controls your name: either by serving a file the authority asks for at your domain, or by writing a record into your DNS. Anything that breaks the proof breaks the renewal. Moving your DNS to a new provider. Putting a proxy in front of the app. Pointing the name somewhere else to try something and pointing it back. Adding a CAA record, which is a DNS entry naming which authorities are allowed to issue for your domain and which quietly forbids every authority it does not name.

None of that takes your site down. The certificate you already have goes on working, so the app stays up and the padlock stays there while the renewal fails again every day for a month with nobody watching.

The letter that used to arrive has also stopped. Let's Encrypt ended its expiration notification emails on 4 June 2025, having announced it in January of that year: renewal is automated for most subscribers now, and holding millions of email addresses against issuance records was a privacy cost they preferred not to carry. Both reasons are good ones. It still removed the one message that reached a human when the automation stopped.

Do Lovable or Vercel renew my certificate for me?

While your app is on the builder's own subdomain, both dates belong to them and neither is something you can get wrong.

On yourapp.lovable.app, or a vercel.app or netlify.app address, the platform owns the name, renews the registration, and issues and renews the certificate. Our own domain check does not even look these up. It reports that the app is on a managed platform domain and that there is nothing here for you to track.

Connecting a domain of your own moves one of the two to you for certain and the other sometimes:

The renewal row is the one people are surprised by. Nothing in the builder announces it. You add a domain, the app loads on it, and you now own a calendar entry you never made.

How do I check both right now?

From outside, without signing in to anything.

The certificate. Open your app, click the padlock in the address bar, open the certificate details and read the "Valid until" date. On a standard 90-day certificate anything more than 30 days out means renewal is working. Less than 30 days means the renewal that should already have happened has not.

The domain. Sign in to your registrar and read three things. The expiry date. Whether the card behind auto-renew is still valid, because auto-renew with a dead card is the commonest way this happens to somebody who was sure it could not. And the email address on the account, which is where every warning you are owed will be sent.

Both at once. Our free scan reads both from outside, along with seven other checks, in about 20 seconds and with no account: scan your app. It prints the certificate's end date and, for a domain you registered yourself, the registration's. On a builder subdomain it says so rather than inventing a date for you.

What we found across 30,998 apps

Both findings are rare, and every single one of them belonged to somebody who had connected a domain of their own.

Between 12 and 14 August 2026 we ran the same nine external checks over 30,998 live apps built with Lovable, Bolt, v0, Replit and Base44. Of the apps each check got an answer from, 55 out of 30,980 had a domain expired or expiring, and 32 out of 30,851 had a certificate expired, expiring or untrusted. The full numbers are in our scan report.

That is 87 apps, which reads like a rounding error until you ask who they were. 1,090 of the scans in that sweep were on an app whose owner had registered the domain. All 87 were in that group, and not one app on a builder subdomain carried either finding. Among the apps that can have this problem at all, that is roughly one in twelve.

Most of that column is a warning rather than an outage, and that is the useful part: somebody still had time. Five of the domains were inside seven days and one had already gone. Thirteen of the apps were showing every visitor a browser warning at the moment we looked, five with an expired certificate and eight with one nothing trusts.

Both of these are a date going past while nobody looks at it, which is the kind of problem something checking every hour is actually good at.

Reeve Monitor re-runs all nine checks every hour on up to three apps, watches uptime every 60 seconds and sends a monthly report. For these two findings it does something it does for nothing else: it emails you about a certificate or a registration running out even when your grade has not changed. Monitor is $12 a month at list, with seven days free before it charges you, and the pricing page is sometimes below the figure here and never above it.

Monitor watches and nothing more. If you also want a copy of your database kept somewhere your builder cannot reach it, that is Care, and it covers Supabase.

What to do right now

Neither of these is a mistake anyone made in your app, which is why they are so easy to leave off the list. Put them on it. If you would rather work through everything at once, the 10-minute security checklist covers all nine checks in the order they are worth doing.