Project shows Healthy but Supabase API hostname returns DNS_PROBE_FINISHED_NXDOMAIN after resuming

[sagisegalis-jpg]

Hello Supabase community,

I'm experiencing a connectivity issue with my Supabase project after it was automatically paused due to inactivity.

Project details:

• Project name: "travel-architecture-app"
• Project ref: "svgiidgrfsuzbkzhvfmx"
• Support ticket: "SU-507251"

I resumed the project, and the Supabase dashboard now shows its status as Healthy. However, the public API hostname still returns "DNS_PROBE_FINISHED_NXDOMAIN".

Project URL:
"https://svgiidgrfsuzbkzhvfmx.supabase.co"

Because the hostname cannot be resolved, my application cannot connect to Supabase and returns the following error:

"TypeError: Failed to fetch"

I have verified that the project is marked as Healthy in the dashboard, but the issue persists.

Has anyone experienced this after resuming a paused project? Is there a way to verify whether the project's public DNS/API hostname has been provisioned correctly?

I need to restore connectivity while preserving my existing database, data, and configuration. I do not want to recreate the project.

Any help would be greatly appreciated.

Thank you.

[cekuu35]

NXDOMAIN on the main API hostname after a pause/resume is a DNS-propagation issue — the dashboard "Healthy" check confirms the database is running, but the DNS record for <project-ref>.supabase.co may not have propagated back to your resolver yet. Three checks in order:

1. Confirm the record actually exists (bypass your local resolver):

nslookup svgiidgrfsuzbkzhvfmx.supabase.co 8.8.8.8
nslookup svgiidgrfsuzbkzhvfmx.supabase.co 1.1.1.1

If Google's or Cloudflare's resolvers return an A record but your default resolver still says NXDOMAIN, it's a negative-cache issue on your side — the NXDOMAIN answer got cached locally. Flush it:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd-resolved): sudo resolvectl flush-caches

2. If public resolvers also return NXDOMAIN, the DNS record genuinely hasn't been re-published after the resume. This happens when the re-provisioning is still completing internally — the "Healthy" badge means the Postgres core is up; the edge/DNS layer can trail it. In that case, this is squarely in support's court (your ticket SU-507251 is the right move), and it's worth noting to them that both public resolvers return NXDOMAIN — that's your evidence it's platform-side, not local.

3. The test that proves which side you're on:

curl -s -o /dev/null -w "%{http_code}" https://svgiidgrfsuzbkzhvfmx.supabase.co/rest/v1/

• HTTP 401 = the API is reachable (just needs auth) — DNS is fine, the problem was local cache
• Connection error = DNS genuinely not propagated yet

For anyone's future pause/resume cycles: the practical expectation on the Free plan is that full re-provisioning (database plus DNS plus the pooler's tenant registration) can take several minutes after the dashboard shows green, and stale negative DNS answers on the client side extend the outage well past the platform's actual recovery time.

For the pooler-side variant of this (Supavisor returning ENOTFOUND after resume), the adjacent thread has that half: #51649 (comment)