Managed Supabase project stuck Unhealthy — Auth/PostgREST return HTTP 521 after restart

[Morbiato]

Hi,

I have a managed Supabase staging project that is currently stuck in an
Unhealthy state.

The failure appears isolated to Auth and PostgREST/Data API.

Observed behavior:

• Dashboard project status: Unhealthy
• Auth requests with valid project client credentials: HTTP 521
• REST/PostgREST table requests: HTTP 521
• Public RPC requests: HTTP 521
• Internal /auth/v1/health: repeatedly HTTP 521
• Internal /rest-admin/v1/ready: repeatedly HTTP 521
• Storage: reachable / HTTP 200
• Edge Functions: reachable / HTTP 200
• Application Worker: reachable / HTTP 200

Already verified:

• project URL is correct
• publishable key belongs to the correct staging project
• request headers are correct
• no CPU, RAM, disk or connection saturation is reported
• no relevant global Supabase incident is currently visible

The Supabase AI Assistant also confirmed from internal logs that
/auth/v1/health and /rest-admin/v1/ready repeatedly return HTTP 521.

I performed one official project restart from the Supabase Dashboard.

The restart was accepted, but after approximately 10 minutes the project
remained Unhealthy and Auth/REST/RPC continued returning HTTP 521.

Post-restart:

• Auth: 521
• REST: 521
• RPC: 521
• Storage: 200
• Edge: 200

I stopped after that single restart.

I have NOT:

• recreated the project
• paused/restored the project
• changed configuration
• rotated keys
• applied migrations
• used direct PostgreSQL as a workaround

Supabase Support has already been contacted.

Has anyone encountered a managed Supabase project where Auth and
PostgREST origins remain unavailable with HTTP 521 while Storage and
Edge stay healthy?

Is there any safe, non-destructive diagnostic or recovery step
available to project owners, or does this normally require Supabase
infrastructure intervention?

I would prefer not to recreate the project unless absolutely necessary.

Thanks.

[Morbiato]

Hi and thank you for your reply! I followed your instructions on the affected project yhfngphapcgverhcufnc ( r7m-ledger-staging). The Pause operation fails immediately with: Failed to pause project: Failed to verify backup status before pausing I can also see repeated HTTP 521 responses for: - /auth/v1/health - /rest/v1/ - /rest-admin/v1/ready - /admin/v1/walg/check-async-backup So the self-service Pause & Restore workaround cannot complete because the platform itself cannot reach the backup verification endpoint. Could you please intervene server-side or advise the next safe action for this project?

…

On Fri, 14 Aug 2026 at 17:15, Christian Alberto ***@***.***> wrote: Hi @Morbiato <https://github.com/Morbiato> Honestly, you can't fix this yourself from the dashboard. An HTTP 521 means Cloudflare's gateway is trying to reach the Auth and PostgREST applications, and those specific containers are dead or frozen. Since Storage and Edge Functions are still returning 200s (they run on separate infrastructure), your underlying Postgres database is fine. What crashed is the internal proxy container that hosts Auth and the Data API. The Only Self-Serve Trick to Try Do a full Pause & Unpause (Pause and Restore) cycle: Go to Project Settings > General Settings > Pause Project. Wait 3 to 5 minutes until the status turns to PAUSED. Click Restore Project. Why this instead of a normal Restart? A Restart just sends a soft reload signal to existing processes. A Pause/Restore completely tears down the broken containers on Supabase's host and spins up fresh ones on clean compute. It usually clears gateway/socket hangs without losing any data. If Pause fails or gets stuck: Don't waste more time or recreate the project. The platform's control plane is stuck, and a Supabase infrastructure engineer has to manually kick the host container. Reply directly to the support ticket you already opened with this exact message: "Storage and Edge Functions return HTTP 200, so Postgres is healthy. However, Auth and PostgREST containers are dead and returning HTTP 521 at the gateway. Soft restart failed. Please hard-reboot or re-provision the project's API proxy container." — Reply to this email directly, view it on GitHub <#48947?email_source=notifications&email_token=A6CECWFE4CBJXW4LIS5VYOT5J4UHVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQGE4DSOJVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18018995>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6CECWAX5GIK6IRFPWGRRUD5J4UHVAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBVHE2TCNZUUF3AE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Morbiato]

Hi, thank you for the clarification and for looking into this. Understood — I’ll leave the project completely untouched from my side and wait for Supabase Support to handle the infrastructure issue. Please keep me updated once the affected services have been re-provisioned or recovered, or if you need any further information from me. Thanks again for your help.

…

On Fri, 14 Aug 2026 at 18:11, Christian Alberto ***@***.***> wrote: Hi @Morbiato <https://github.com/Morbiato>, Thanks for testing that. In this case, I would *not attempt Pause/Restore again*. The new Failed to verify backup status before pausing error, together with the 521 responses from /admin/v1/walg/check-async-backup, changes the situation quite a bit. At this point, the failure is not limited to Auth/PostgREST. The platform is also unable to reach the backup verification service required by the pause operation itself. Since: - the normal project restart already failed to recover Auth/PostgREST, - /auth/v1/health returns 521, - /rest-admin/v1/ready returns 521, - /admin/v1/walg/check-async-backup returns 521, - Storage and Edge Functions remain healthy, I would leave the project untouched and let Supabase Support handle the infrastructure side. I definitely would *not recreate the project* at this stage, especially since the database/data appears to remain intact and you already have an open support ticket. I would update the ticket with the exact Pause error and mention that the backup verification endpoint itself is returning 521. That gives Supabase's infrastructure team a much stronger signal that this is a platform-side recovery/control-plane issue rather than a project configuration problem. Hopefully Support can re-provision or repair the affected services without requiring a project recreation. — Reply to this email directly, view it on GitHub <#48947?email_source=notifications&email_token=A6CECWF7DRAFPN2CU3LC2YD5J422PA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQGE4TMNBTUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18019643>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6CECWFIO6G3MYVRPEWUTY35J422PAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBVHE2TCNZUUF3AE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Morbiato]

Hi, thank you again for your help and for keeping an eye on this. I’ll leave the project untouched and periodically check whether Auth and PostgREST are back online. Once the affected services are fully recovered, I’ll be happy to mark the answer as accepted. Thanks again, and I’ll wait for the recovery.

…

On Fri, 14 Aug 2026 at 21:03, Christian Alberto ***@***.***> wrote: Hi! You’re very welcome. With this, I believe your question has been answered. As soon as I have confirmation that the affected services have been fully recovered, I’ll do my best to let you know. That said, you may notice it yourself before I’m able to update you, simply by testing the affected services again. In any case, if you feel that your question has been resolved, please consider marking the answer above as the accepted answer. This would help other members of the community who may encounter the same issue in the future. Thanks again, and I hope everything is back to normal soon! — Reply to this email directly, view it on GitHub <#48947?email_source=notifications&email_token=A6CECWEDVW7K7OUUUDPXJYT5J5PAHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQGIYTEMBRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18021201>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6CECWGKNB53FL3TG54IOGD5J5PAHAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBVHE2TCNZUUF3AE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GaryAustin1]

Not sure what the person answering is up to but they have no inside info and appear to be using mainly AI to answer.

You should never try and pause an unhealthy project if you need it as chances are high it will completely lock up.

Burst disk i/o is the usual issue for this. Make sure your app is not looping on REST API errors. This can keep disk i/o burst from replenishing which happens over 24 hours slowly.

You have to try restart occasionally or wait for support to restart which if Free could be several days.

Another option is to go Pro and upgrade the instance which almost always solves the issue and would get you faster support if not.