Production project unhealthy: repeated 521 responses from internal readiness and Auth health checks

[BOchs8]

We have an active, project-specific Production outage and are looking for advice from anyone who has encountered similar behavior.

Project environment

Supabase Pro plan
Micro compute
Region: East US (North Virginia)
No deployment, migration, configuration, or database change occurred near the outage
Official Supabase status page reports all systems operational

Timeline — August 8, 2026

Last known successful request: 18:18:39 UTC
First failure: 18:49:56 UTC — Auth refresh returned 525
First 521: 18:49:57 UTC
Application RPC confirmed returning 521: 18:50:00 UTC
The project has remained unhealthy since then

Dashboard observations

Project status: Unhealthy
CPU: approximately 97%
RAM: approximately 39%
Disk: approximately 4%
Large number of API Gateway 5xx responses

Internal checks repeatedly fail approximately every five seconds:

HEAD /rest-admin/v1/ready → 521
GET /auth/v1/health → 521
POST /admin/v1/network-bans/retrieve → 521

Normal application operations also return 521, including:

POST /rest/v1/rpc/get_current_directory_spotlight
POST /rest/v1/rpc/get_regulatory_agency_by_slug
POST /auth/v1/token?grant_type=refresh_token

The internal requests are identified as originating from Supabase’s management infrastructure. Application REST, RPC, and Auth traffic reaches the API Gateway but cannot reach the backing services.

We also checked the application-hosting side:

The Production deployment remained unchanged and healthy
No Production deployment or alias movement occurred around the incident
The application host continued returning page shells successfully
Deduplicated request logs do not show a meaningful traffic storm
No evidence currently indicates unauthorized access or a data breach

We have not restarted or resized compute, terminated sessions, revoked tokens, or changed configuration. A paid support request is open.

Has anyone encountered a Supabase project where REST readiness and Auth health checks continuously return 521 while the dashboard reports Unhealthy and high CPU?

In particular:

Was provider intervention required to restore the project services?
Is a project restart advisable in this state, or should we wait for Supabase support?
Are there additional read-only diagnostics we can collect without adding load to the unhealthy database?

[GaryAustin1]

This normally means you overloaded the database.
Check disk i/o and look for disk burst warnings also.

If your app goes into loops retrying on error this is a very typical system after an error or two the system gets pounded with retries for the API including Auth. When this happens even restart will not have enough disk i/o to come back up. Stop all API access and then restart.

Note disk i/o burst slowly improves each hour for 24 hours if not taxed.

Upgrading instance size if very common way to address if you are not sure what to reduce API/SQL wise to reduce load.

Check the API Gateway log and charts to see if you have an influx of requests.

[BOchs8]

Gary;
Thank you
Your guidance was very helpful.

We stopped our diagnostic traffic, confirmed there was no active recovery or infrastructure operation, and performed exacty one supported project restart. We did not resize, upgrade, restore, or make any database changes.

The restart took approximately seven minutes.

The project returned to Healthy
Database, PostgREST, Auth, Storage, Realtime, and Edge services all became Healthy
The internal REST readiness and Auth health checks changed from 521's to 200's
Our public data backed pages began loading normally agan
No additional 521 errors appeared during the initial verification
We are continuing to monitor stability and have asked Supabase support to review the earlier CPU and disk-I/O telemetry so we can identify the underlying cause. The restart restored service, although we are not yet assuming it fixed the root problem.

Thanks again for pointing us toward resource pressure, retry behavior, and a controlled restart.
Now....What happened :)

[BOchs8]

Gary;
Thank you
Your guidance was very helpful.

We stopped our diagnostic traffic, confirmed there was no active recovery or infrastructure operation, and performed exacty one supported project restart. We did not resize, upgrade, restore, or make any database changes.

The restart took approximately seven minutes.

• The project returned to Healthy
• Database, PostgREST, Auth, Storage, Realtime, and Edge services all became Healthy
• The internal REST readiness and Auth health checks changed from 521's to 200's
• Our public data backed pages began loading normally agan
• No additional 521 errors appeared during the initial verification

We are continuing to monitor stability and have asked Supabase support to review the earlier CPU and disk-I/O telemetry so we can identify the underlying cause. The restart restored service, although we are not yet assuming it fixed the root problem.

Thanks again for pointing us toward resource pressure, retry behavior, and a controlled restart.
Now....What happened :)