INC-004: A client's store went dark, and I debugged the wrong thing twice

I assumed the backend host was the problem, then a free-tier cold start. Both were wrong. The frontend actually lived on Cloudflare Pages, and a detach/reattach of the custom domain had left it...

severity: SEV-1 | kind: outage | date: 2026-08-14 | status: RESOLVED

Impact

nufab.store returned Cloudflare 522 errors to many visitors; the client was getting customer calls while it was down.

Summary

I assumed the backend host was the problem, then a free-tier cold start. Both were wrong. The frontend actually lived on Cloudflare Pages, and a detach/reattach of the custom domain had left it stuck and deleted its DNS record.

Timeline

• Reports of 522 'host error' on the root domain
• First theory: backend on Render was down / cold-starting
• Ruled out: the Render service was on a paid always-on plan
• Checked DNS: the root domain pointed at Cloudflare Pages, not Render
• Found the custom domain stuck as 'already associated' after an earlier detach/reattach; the root CNAME had been deleted
• Restored the root CNAME to the Pages project (proxied)
• Re-attached the custom domain: Verifying → Active, SSL issued
• Remaining 'still down' reports were stale local DNS caches; flushed and confirmed

Root cause

Changing a custom-domain attachment removed the DNS record the domain depended on, and I didn't have an up-to-date map of which service served which part of the site.

What didn't work

• Diagnosing the backend host first
• Assuming a free-tier cold start

Resolution

• Restore DNS record
• Re-attach custom domain
• Verify SSL
• Flush stale client DNS caches

Action items

• [ ] Keep an infra map: domain → DNS → host per service
• [ ] External uptime check on the root domain

Lesson

_Before debugging, confirm where the thing actually runs. I spent the first part of the outage fixing a service that was fine._

tags: cloudflare, dns, render, incident-response