DNS cutover left the site half-broken
After moving hosts or domains, behavior depends on who's looking: some visitors get the new site, some the old one, some a certificate warning or a hosting provider's default page. It "works on your machine" while support tickets disagree.
- Webflow
- Bubble
- Any stack
- DNS & SSL
Root cause, in plain English
DNS changes don't propagate atomically — every resolver caches each record for its TTL, so for hours different visitors resolve different answers. Cutovers also move piecewise: the apex record updated but www still points at the old host, a subdomain's CNAME was forgotten, or the new host hasn't verified the hostname yet, so it answers with a certificate error or a default landing page. Half-broken is the natural state of a cutover; the work is making it short and complete.
How to fix it
List every record in the zone before touching anything — apex, www, api, mail-related TXT records (SPF/DKIM/DMARC) — and decide each one's destination. The forgotten record is the one that breaks.
Lower TTLs on the records you'll change to 300s, a day before the cutover, so the stale window shrinks from hours to minutes.
Add the custom domain on the new host first and let it verify and issue certificates before you flip DNS — pointing traffic at an unverified host is what produces the default-page and SSL-warning symptoms.
Flip the records as one batch, then verify from multiple resolvers: dig @1.1.1.1 and dig @8.8.8.8 for each hostname, plus a phone on cellular data.
Keep the old origin serving (or redirecting) until TTL-stale traffic drains, and immediately re-test the things that embed your domain: OAuth redirect URLs, webhook endpoints, and email authentication records.
Go deeper: copy the open-source health-check recipe.
How Nightlamp detects this automatically
- HTTP status
- Keyword check
- SSL expiry
- Visual snapshot
External http_status and http_keyword checks probe every hostname from outside your network and assert your real content answers — a parking page or wrong origin serves 200 but fails the keyword. An ssl monitor verifies the new host's certificates per hostname, and a visual_snapshot catches the "default page" failure mode at a glance.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- How long does DNS propagation actually take?
- Exactly as long as the TTL that resolvers cached before your change — typically one to twenty-four hours if you didn't lower it first. "Propagation" isn't a push; it's old answers expiring. Lowering TTL in advance is the only lever.
- Why do I see the new site while my customer sees the old one?
- You're using different resolvers with different cache ages, and your own machine may also have OS or browser DNS caches. Test from a resolver you didn't just use (dig @8.8.8.8) and a network you're not on, before declaring the cutover done.
- What's the most commonly forgotten record in a cutover?
- Email-related ones: the SPF/DKIM/DMARC TXT records and any MX hosted with the old provider. The website moves cleanly, then receipts and magic links start failing days later — see the transactional-email pattern for what that looks like.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.