The 5 Minutes My Site Was Down and What I Learned

I made a routine infrastructure change today. Switched from Firebase Hosting to Vercel. Should be straightforward, right? Update some config, push to GitHub, point the DNS, done.

And then the site went dark.

Not for long. Maybe five minutes. But five minutes of watching your project return nothing but a blank page feels like five hours. I refreshed obsessively. Checked the Vercel dashboard. Checked Firebase. Opened different browsers. Tried my phone. Nothing.

The rational part of my brain knew this was normal. DNS propagation takes time. The old records were fading out, the new ones fading in. Somewhere in between, requests were going nowhere.

The irrational part of my brain was convinced I had broken everything permanently.

Why DNS Still Terrifies Me

I've been doing this for years. I understand how DNS works. I know that when you update nameservers or A records, it takes time for those changes to propagate across the internet. Different ISPs cache records for different amounts of time. Some users will see the new site immediately, others might take hours.

Knowing all of this doesn't make it less stressful.

The problem with DNS is that you can't really test it. You make the change and then you wait. You can use tools to check propagation status, but ultimately you're just sitting there hoping it works. There's no staging environment for DNS. No preview deploy. You flip the switch and hold your breath.

What Actually Happened

The migration itself was simple. Vercel auto-detected my Next.js project, ran the build, deployed it. The preview URL worked perfectly. All I had to do was update the DNS records to point my domain at Vercel instead of Firebase.

I logged into my domain registrar, updated the records, and saved. Then I waited.

The old site stayed up for about a minute. Then it went down. Then nothing. The new site wasn't responding yet. My browser was caching the old DNS, which was now pointing at a Firebase project that was no longer serving the site.

I cleared my DNS cache. Still nothing. Tried a different network. Nothing. Pulled out my phone on cellular. Finally, the new site appeared.

Total downtime was probably five minutes. Felt like an eternity.

Lessons for Next Time

A few things I'd do differently.

First, lower the TTL before making changes. TTL is the time-to-live value that tells DNS caches how long to hold onto a record. If your TTL is set to 24 hours, some users might see stale records for up to 24 hours after you make a change. If you know you're going to switch providers, lower your TTL to something like 300 seconds (5 minutes) a day or two before the migration. That way caches will refresh faster when you make the actual switch.

Second, have both the old and new hosting running simultaneously during the transition. I could have kept Firebase serving the site while Vercel was ready and waiting. Once DNS propagated, traffic would seamlessly shift to Vercel. Instead I was in a rush and pulled the trigger before confirming everything was ready.

Third, don't do infrastructure changes at peak traffic times. I did this in the middle of the afternoon because I was impatient. Should have done it at 2 AM when nobody was visiting anyway.

The Upside

The reason I switched was to enable some new functionality. Vercel handles hybrid Next.js apps natively, which means I can have server-side API routes alongside static pages. Firebase Hosting is great for static sites, but I needed a bit more flexibility.

Now I can add features that require backend logic without spinning up a separate server. The admin tool I was building actually works in production now, not just locally.

Was five minutes of stress worth it? Probably. The new setup is more capable and just as fast. But I won't pretend I enjoyed watching that 404 page.

Tools That Help

When you're debugging deployment issues, having reliable tools to inspect your data helps. I use my own JSON Formatter constantly when checking API responses and config files. Vercel's deployment logs are JSON, build configs are JSON, error responses are JSON. Being able to quickly format and validate that data saves time when you're panicking.

For tracking unique deployment IDs and request traces, having a UUID Generator handy is useful too. Vercel assigns unique IDs to every request, and being able to generate your own for testing helps when you're trying to trace what's happening.

The Boring Stuff Matters

Infrastructure work isn't glamorous. Nobody's impressed by a successful DNS migration. But getting it wrong can take your entire project offline.

Take your time with it. Lower your TTLs in advance. Keep the old setup running until you're sure the new one works. And maybe don't do it when you're impatient and rushing to ship a new feature.

The site's back up now. Everything works. But I'm definitely waiting until 2 AM next time.

Tools mentioned in this article:

• JSON Formatter - Format and validate JSON config files
• UUID Generator - Generate unique identifiers for tracking