It wasn’t DNS — but everyone had already decided it was
August 1, 2026
My site went down. It had gone down shortly after I moved its DNS to a new provider, which meant everybody — me included — already knew what the problem was before anyone looked at anything. That confidence cost real time, because the DNS change was completely innocent, and the actual cause was two small decisions made months earlier that nobody would have described as risky.
The detail that ruled out the obvious answer
Every site gets a free hosting-provider address alongside its real domain — something ending in the platform’s own domain rather than yours. That address was down too.
That single fact ends the DNS theory. Your DNS settings control where your domain points. They have no power whatsoever over an address the hosting platform owns and resolves itself. If both are down, the problem is behind both of them, and no amount of staring at DNS records will find it.
The general form of this is worth keeping: when you have a prime suspect, look for the thing your suspect cannot possibly explain. If you find one, you’ve saved yourself an afternoon.
What was actually wrong: two cheap decisions
The site pulls some of its content from a small backend service. That service ran on a free hosting plan, and free plans put your service to sleep when it’s idle. Normally it wakes up when a request arrives. This time it didn’t wake up.
On its own that should have been survivable — most of the site doesn’t need that service. But the code that fetched the content had no timeout. It was written to wait for an answer, and it did, indefinitely. So a sleeping backend didn’t degrade one section of one page. It hung every page render, and it hung the build too, which then failed for taking longer than the platform allows. One unresponsive dependency, no time limit, whole site gone.
The fixes, in order of how much they mattered
There was a third finding, too, and it’s the one I’d watch for in any business: a background job processor was described in the configuration but had never actually been created. Everything referenced it. Nothing ran it. Queued email jobs had simply been accumulating, unnoticed, because nothing fails when a worker that doesn’t exist doesn’t do anything.
- Put a time limit on every call to something you don’t control. Eight seconds here. A dependency that is slow or dead now fails fast and visibly instead of hanging forever.
- Move anything customers depend on off a free tier. Free plans sleep. That is the product, not a bug — you are choosing downtime in exchange for the price.
- Decide what a page should do when the data isn’t there. Failing fast is only an improvement if something sensible happens next.
What this costs a business, in plain terms
Free and near-free infrastructure is genuinely fine for the parts of your system nobody is waiting on. It is a poor choice for anything in front of a customer, and the failure mode isn’t a clean error page — it’s a slow hang, which is worse, because visitors wait a while before deciding you’re broken.
The other half is the diagnosis. Outages get blamed on the most recent change, because that’s how humans reason. It’s a good instinct and it is wrong often enough to be expensive. Before acting on the obvious cause, spend thirty seconds looking for evidence that contradicts it.
The takeaway
Blame the most recent change, but verify it first — look for the symptom your prime suspect can’t explain. Then put a timeout on every external call and keep customer-facing services off free tiers that sleep.
Capabilities this touches