Project is Healthy but API hostname returns DNS_PROBE_FINISHED_NXDOMAIN

[mgan76]

Hello,

I have a Supabase project named Epacks360 that is shown as Healthy in the Supabase Dashboard, and the Primary Database is running normally.

Project details:

Project name: Epacks360
Project ref: tsdfwmphfhkxkthtgspn
Region: us-west-2 (West US / Oregon)
Data API: Enabled
Support ticket already opened: SU-484337

The Supabase Dashboard displays the project URL as:

https://tsdfwmphfhkxkthtgspn.supabase.co

And the Data API URL as:

https://tsdfwmphfhkxkthtgspn.supabase.co/rest/v1/

However, the project hostname does not resolve in DNS.

When opening the project URL directly in a browser, I receive:

DNS_PROBE_FINISHED_NXDOMAIN

My application also cannot access Supabase Auth. Requests to:

/auth/v1/health

fail with:

net::ERR_NAME_NOT_RESOLVED

I have tested the hostname from different devices and different networks, including a mobile 4G/5G connection with Wi-Fi disabled, and the result is the same.

The database itself is active and the Supabase Dashboard reports the project as Healthy, so this appears to be related to the provisioning/resolution of the public *.supabase.co hostname.

Has anyone experienced this recently? Is there anything that can be done from the project side, or does the DNS record need to be reprovisioned by Supabase?

I would like to preserve the existing project, database structure and configuration, rather than recreate the project.

Thank you.

[Abdurrahman-Sudais]

Yeah this looks like a DNS provisioning gap on Supabase's side rather than anything wrong with your project itself. The dashboard checks health against the DB directly, but the public hostname is a separate DNS record that has to be provisioned on their edge layer, and those two things can get out of sync, especially after a pause/resize/restore.
Quick things to rule out first: make sure tsdfwmphfhkxkthtgspn in the URL is exactly what's showing under Project Settings > General right now (not something cached in an old .env somewhere). Assuming that checks out, try resolving it against a couple of public resolvers directly instead of just your own network:
dig tsdfwmphfhkxkthtgspn.supabase.co @8.8.8.8
dig tsdfwmphfhkxkthtgspn.supabase.co @1.1.1.1
If those also come back NXDOMAIN (not just timing out or SERVFAIL), that basically confirms the record isn't in their zone at all right now, it's not a caching thing on your end. You've already tested across devices/carriers so I'd guess this is where you'll land anyway.
Given you've got SU-484337 open already, I'd reply on that ticket with the dig output above. Support tends to move faster once you hand them proof it's not client-side, since "have you tried flushing DNS" is usually the first bounce-back otherwise. This has happened to a few other people after pause/restore cycles so it's a known-ish class of issue on their end, just needs someone to manually kick the provisioning for your specific ref.
Cool?

[mgan76]

Hello, I performed additional DNS tests using two independent public DNS resolvers, as suggested by the Supabase community. *Google Public DNS (8.8.8.8):* nslookup tsdfwmphfhkxkthtgspn.supabase.co 8.8.8.8 Result: Non-existent domain *Cloudflare DNS (1.1.1.1):* nslookup tsdfwmphfhkxkthtgspn.supabase.co 1.1.1.1 Result: Non-existent domain Both independent public resolvers return NXDOMAIN for the project hostname. The project still appears as *Healthy* in the Supabase Dashboard, the Primary Database is active, and the Data API is enabled. This strongly indicates that the public DNS record for project ref tsdfwmphfhkxkthtgspn has not been provisioned correctly. Could you please check and reprovision/restore the public *.supabase.co DNS hostname for this existing project? *Support ticket: SU-484337* Please preserve the existing project and database, as it already contains our database structure and configuration. Thank you.

…

On Thu, Sep 24, 2026 at 3:34 PM 🌹 Abdurrahman Sudais 🏆💕🌹 < ***@***.***> wrote: Yeah this looks like a DNS provisioning gap on Supabase's side rather than anything wrong with your project itself. The dashboard checks health against the DB directly, but the public hostname is a separate DNS record that has to be provisioned on their edge layer, and those two things can get out of sync, especially after a pause/resize/restore. Quick things to rule out first: make sure tsdfwmphfhkxkthtgspn in the URL is exactly what's showing under Project Settings > General right now (not something cached in an old .env somewhere). Assuming that checks out, try resolving it against a couple of public resolvers directly instead of just your own network: dig tsdfwmphfhkxkthtgspn.supabase.co @8.8.8.8 dig tsdfwmphfhkxkthtgspn.supabase.co @1.1.1.1 If those also come back NXDOMAIN (not just timing out or SERVFAIL), that basically confirms the record isn't in their zone at all right now, it's not a caching thing on your end. You've already tested across devices/carriers so I'd guess this is where you'll land anyway. Given you've got SU-484337 open already, I'd reply on that ticket with the dig output above. Support tends to move faster once you hand them proof it's not client-side, since "have you tried flushing DNS" is usually the first bounce-back otherwise. This has happened to a few other people after pause/restore cycles so it's a known-ish class of issue on their end, just needs someone to manually kick the provisioning for your specific ref. Cool? — Reply to this email directly, view it on GitHub <#50875?email_source=notifications&email_token=CPQIGGKTS46K7UBN2NZXT6D5QVSMRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVHA2TMNJRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18585651>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CPQIGGO4J4AXASVW45BIZWT5QVSMRAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBYG44TOMBVUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CPQIGGO6MRONNEUHTRF7HZL5QVSMRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVHA2TMNJRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CPQIGGODNN3OE2YBHL24QF35QVSMRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVHA2TMNJRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[psps2930-web]

Hello, I am experiencing the same issue with my Supabase project.

Project name: 세상읽기노트
Project ref: utuuvlbmsuirmkvxwbdx
Region: Northeast Asia (Seoul), ap-northeast-2

The Supabase Dashboard shows the project as Healthy and the Data API is enabled, but the public API hostname does not resolve:

https://utuuvlbmsuirmkvxwbdx.supabase.co

Chrome previously returned:
DNS_PROBE_FINISHED_NXDOMAIN

I also confirmed:

nslookup utuuvlbmsuirmkvxwbdx.supabase.co
→ Non-existent domain

and:

nslookup utuuvlbmsuirmkvxwbdx.supabase.co 8.8.8.8
→ Non-existent domain

I have already completed a full Pause → Resume cycle. The project was successfully restored and now shows Healthy, but the hostname still returns NXDOMAIN.

I also opened a Supabase Support ticket:
SU-487771

Could Supabase please check whether the public DNS/API hostname for this project needs to be re-provisioned?

I would like to keep the existing project, database, Auth configuration, and project reference rather than creating a new project.

Thank you.

[GaryAustin1]

You will have to wait on your support ticket if Pause/Restore, restart did not resolve it.

[pavithraB-wec]

The combination of a Healthy project in the Supabase dashboard and an NXDOMAIN response for the project hostname suggests a DNS/hostname resolution issue rather than a database availability issue.

Since you have already tested multiple public DNS resolvers, I would also check the hostname directly:

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

It would also be useful to test the hostname from another network, such as mobile data, to rule out a local DNS or network issue.

If the hostname consistently returns NXDOMAIN across different networks and DNS resolvers while the project remains Healthy in the Supabase dashboard, this could indicate that the DNS record for the project hostname has not been properly provisioned.

If restarting or pausing/restoring the project does not resolve it, the existing Supabase support ticket seems like the appropriate next step so the project hostname/DNS configuration can be checked on the Supabase side.