sa-east-1: project down 2 hours, restart failed (capacity), resize completed but still 522 on Auth/REST

[alexandreabussafi]

Production project has been down for several hours and I can't get it back despite trying everything available to me. Posting here since official support response is delayed (very high ticket volume per their auto-reply).

Project: jyupvxxpyhuyzeofrnjo (sa-east-1, Pro plan)

What happened:

• Database/PostgREST/Auth/Storage all went Unhealthy, with REST and Auth endpoints returning 522
• A manual restart from the dashboard failed with a "capacity issues" error
• I then resized from SMALL to MICRO. The resize completed and the dashboard shows the project as Active/Healthy, but the database still isn't serving requests — same 522s persist on /rest/v1/... and /auth/v1/... endpoints, and direct SQL connections time out

Support tickets: SU-408345 and SU-408392 (no human response yet)

Has anyone run into this before — restart/resize completing at the infrastructure level but the database still not accepting connections afterward? Or does this connect to the open "Project status change failures in multiple regions" incident on the status page? Any pointers welcome while I wait on a ticket response.

[GaryAustin1]

Why would you resize down from small to micro? If the project shows the correct size though I would think you got thru the capacity "gauntlet".

You need to make sure your app is not continuing to hit the database also. I've seen cases where user code does loop retries with no backoff. This will pile up with a wall of requests that eat up the disk i/o burst for any of the nano/micro/small projects so they never come up.

[alexandreabussafi]

Thanks Gary. Quick correction to my original post: the SMALL → MICRO resize did not actually complete — I couldn't get it to go through. So the project should still be on its original size, not MICRO. That was my mistake in the first write-up.

Now it makes sense: resize and restart operations are both failing for me with capacity errors, which matches exactly what the open status-page incident "Project status change failures in multiple regions" describes (project creation, resizing, branch provisioning and restarts failing). I'm in sa-east-1 (São Paulo), and another user in this same forum reported an identical 522 / Unhealthy pattern in the same region — so this looks like the regional capacity incident reaching sa-east-1 even though it isn't explicitly listed there.

Current state:

Database / PostgREST / Auth / Storage show Unhealthy
REST (/rest/v1/...) and Auth (/auth/v1/token) endpoints return 522 / 503
Direct SQL connections time out
Manual restart fails with a capacity error, and resize won't complete either
I've stopped retrying the restart/resize so I'm not piling onto the queue, and I'm putting the app in maintenance to stop client retries from hammering the origin while it tries to recover.

Question for the team: can you confirm whether sa-east-1 is covered by the current multi-region capacity incident? If restart/resize are blocked by capacity on your side, is there anything I can do from my end, or is it purely a wait-for-capacity situation?

Open tickets: SU-408345, SU-408392.

[GaryAustin1]

"your side"... I'm not a Supabase employee. I have flagged this because of a couple of other Discord reports thru our informal path to them. So it is up to support or someone to see my Slack message to start working the issue. Seems like either DNS or something in the DC there as close to 1/2 dozen live projects down and that is NOT the status report issue which is just upgrade/downgrade type things...

[alexandreabussafi]

Ha, thanks so much for jumping on this, Gary — and sorry for the "your side" bit earlier, my bad! 😅 Totally get now that you're doing us all a favor through your channel. Really appreciate you flagging it. 🙏

Just adding one more data point to your DC/DNS theory: I'm a live production project in sa-east-1, fully down — not an upgrade/downgrade thing at all. So yeah, that lines up with what you're seeing rather than the status-page incident.

For whoever picks it up on the Supabase side, my tickets are SU-408345 and SU-408392 — happy to share any sb-request-id / CF-Ray values if it helps them correlate. Fingers crossed sa-east-1 comes back soon. Standing by, and thanks again! 🚀

[editcorporiginal]

Hey everyone,

I'm running a Supabase project hosted in the sa-east-1 (São Paulo) region. Since yesterday, my project has been almost completely unreachable. The dashboard shows Database, PostgREST, Auth, and Storage as "Unhealthy", and my overall success rate is sitting at around 8.5%.

I tried to debug it with a simple curl -I request to my REST endpoint, and I got a Cloudflare HTTP 522 error – which means the Cloudflare edge can reach my project, but the origin server (my compute instance) is timing out and not responding to the network request.

Here's the exact response I got:

http
HTTP/1.1 522
Date: Tue, 30 Jun 2026 23:58:34 GMT
Content-Type: text/plain
Content-Length: 7330
CF-Ray: a1411e2c29e63012-EZE
Retry-After: 120
Server: cloudflare
sb-project-ref: [REDACTED]
sb-request-id: 019f1af8-17a1-76e2-8d35-f291f24a896f

[Guudiass]

@GaryAustin1 ticket é SU-408492.

[Almeidajf37]

SU-408361.
SU-408395.

[editcorporiginal]

Additionally, I found the following logs from the Realtime service. It shows that even internal Supabase services (Realtime) are unable to connect to my project's database, resulting in repeated timeouts and tenant termination:

[2026-06-30 23:57:39] UnableToConnectToProject: Realtime was unable to connect to the project database
[2026-06-30 23:57:39] UnableToConnectToTenantDatabase: Unable to connect to tenant database
[2026-06-30 23:57:39] connection not available and request was dropped from queue after 12000ms
[2026-06-30 23:57:39] Tenant dcuhscyhdjfxfouyyexn has been terminated: :shutdown

This pattern repeats every few seconds, confirming that the origin server (my compute instance) is completely unresponsive.

[editcorporiginal]

I also pulled the Management API logs for my project. The internal health checks (GET /tenants/dcuhscyhdjfxfouyyexn/health) are frequently returning ABORTED REQ, meaning the internal Supabase orchestrator is trying to ping my project, but the connection is timing out and being aborted.

Here is a small sample of the pattern:

• 1782872622... | GET /health | ABORTED REQ
• 1782872617... | GET /health | ABORTED REQ
• 1782872591... | GET /health | ABORTED REQ
• 1782872612... | GET /health | 200 (rare success)
• 1782872580... | GET /health | 200 (rare success)

This proves that the compute instance for my project is not completely dead, but is severely degraded and failing internal health checks most of the time. The few 200 responses suggest the instance is intermittently responsive at the network layer, but the application (Postgres/PostgREST) is not functional.

Given that the Management API itself is aborting connections to my project, this is an infrastructure-level issue that requires a manual hard reset or migration of my project to a healthy node in sa-east-1.

Please escalate this to the infrastructure team.

[GaryAustin1]

You should get this info to your ticket thru support. I have no idea if they will look here or not.
Although I did link this discussion. They normally go on tickets internally.

[GaryAustin1]

Supabase is leaning towards this being tied to the current general capacity outage.
I'm not sure how that would have impacted running projects, but certainly at the point you start upgrading or restarting you could be impacted.
I'll leave it to them to follow up.
Good luck.

[IBBAOG]

Were you able to solve this? Exactly same problem here...