A Live Site Went Down From One DNS Record — Diagnosing and Fixing It With the Cloudflare API

Tabeer.ai went down — the bare domain, not www — right as I was mid-deploy on something unrelated. The failure mode made it look, at first glance, like a broken build. It wasn't. It was one DNS record, and it took about 15 minutes end to end to find and fix using nothing but curl and the Cloudflare API.

The Symptom Was Misleading

https://tabeer.ai/ was returning a 404 — specifically, Nitro's own "where am i?" default error page, which meant the request was reaching the Node process, just for a route it didn't recognize. That's usually a build problem: an incomplete deploy missing a chunk, or a stale route. So the first checks were all build-integrity checks — pgrep for a stuck build process, free -h for OOM pressure, ls on the expected output chunks. Everything came back clean. The build was fine.

The next step is the one that actually mattered: bypass Cloudflare entirely and hit the origin directly.

ssh user@server "curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/"
# 200
ssh user@server "curl -sk -o /dev/null -w '%{http_code}\n' -H 'Host: tabeer.ai' https://127.0.0.1/"
# 200

Both the Node process and nginx in front of it were completely healthy. Which meant the 404 wasn't coming from the application at all — it was happening somewhere between the public internet and the server. That narrows it to exactly one place: DNS or the Cloudflare edge.

The Actual Cause

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE/dns_records?per_page=100" \
  -H "Authorization: Bearer $CF_TOKEN"

A     www.tabeer.ai -> 16.171.2.132   proxied=true
CNAME tabeer.ai     -> a9b75323d6b0cfa271f5.cf-prod-us-proxy.proxyhog.com   proxied=false

There it was. www.tabeer.ai had the correct, working setup — an A record pointing straight at the origin, proxied through Cloudflare. tabeer.ai — the apex, the domain almost everyone actually types — had been repointed to an external CNAME target, with Cloudflare's proxy switched off. created_on on that record was seconds before the outage started.

Two things made this record specifically dangerous, beyond just being wrong:

1. proxied: false on a CNAME means Cloudflare stops protecting and serving that hostname entirely. DDoS mitigation, caching, WAF (what little the plan includes) — none of it applies. Traffic goes straight to whatever the CNAME resolves to.
2. The CNAME target itself wasn't responding. A direct request to https://a9b75323d6b0cfa271f5.cf-prod-us-proxy.proxyhog.com/ timed out. Whatever this third-party "managed proxy" service was meant to do, it wasn't fully provisioned — the apex domain had been pointed at a dead end.

This turned out to be an in-progress setup for a third-party proxy product, added directly to the live apex instead of a throwaway subdomain first. Worth saying plainly: test new DNS-level integrations on a subdomain, never the production apex. A misconfigured staging.yourdomain.com costs nothing. A misconfigured apex is a full outage.

The Fix, via API

Once the bad record was identified, restoring service was two calls:

# Remove the broken CNAME
curl -X DELETE "https://api.cloudflare.com/client/v4/zones/$ZONE/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_TOKEN"

# Recreate it correctly, matching the working www record
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/dns_records" \
  -H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json" \
  -d '{"type":"A","name":"tabeer.ai","content":"16.171.2.132","ttl":1,"proxied":true}'

DNS propagated within a couple of minutes; the apex was serving 200s again shortly after. Total outage window: roughly 13 minutes, start to confirmed-fixed.

What I'd Change Going Forward

• A subdomain, not the apex, for testing new integrations. For anyone who still wants that managed-proxy product live eventually, the right move is standing it up on something like proxy-test.yourdomain.com first — verify it actually round-trips to origin before it ever touches a record real traffic depends on.
• Cache the "bypass the CDN" diagnostic step earlier in the checklist. The build-health checks weren't wrong to run, they just weren't the actual problem — a direct-to-origin curl should be step one whenever a live symptom doesn't match what the server logs show, since it immediately tells you whether the problem is your application or the layer in front of it.
• A narrowly-scoped API token still let me fully diagnose and fix this. The token available only had DNS read/write — no cache purge, no firewall access — and that was enough. Worth remembering when provisioning tokens for anyone or anything touching a zone: DNS-record scope alone covers a surprising amount of real incident response.

If you're dealing with a "site is down but the server looks fine" incident, or want a second pair of eyes on DNS/Cloudflare configuration before it becomes one, get in touch.