Pro production outage: stuck RESTARTING for 13+ hours, no recovery ETA (ca-central-1)

[QuiqueTamayoMX]

Our production backend for https://fertilitycare.lat/ remains unavailable. We are now on the Pro plan, have used the authenticated support form, and need a concrete recovery plan. Acknowledging and escalating a production incident without a recovery estimate or even a scheduled next update is not adequate for an outage of this duration.

Impact

The public directory and Backoffice cannot operate. We deployed an informational-only contingency with a maintenance notice, so a successful HTTP response from the homepage does not mean the Supabase backend has recovered. Database-dependent functions remain unavailable.

Environment and verified symptoms

• Project ref: ndywfyqhzzkhzfctfdir; region: ca-central-1.
• Hosted Supabase; Next.js 16 application on Netlify using Supabase Auth, Postgres, Storage and Edge Functions.
• Last healthy-version evidence (October 24): PostgreSQL 17.6.1.141, Vault 0.3.1; Supabase CLI 2.121.0. These are historical observations, not a claim that the inaccessible instance was re-inspected today.
• Management API/CLI: RESTARTING.
• Earlier incident probes: REST and Auth health returned HTTP 522; SQL reads timed out at 15 seconds. Storage status returned 200 while a bucket query returned 544.
• Latest bounded read, 2026-10-27 at approximately 04:25 UTC: project status still RESTARTING; project health request returned HTTP 400.

Timeline — UTC

• October 26, 02:01: read-only probes documented timeouts in the website, directory, Auth and REST. The exact beginning of the outage is unknown; the documented failures now span more than 26 hours.
• October 26, 14:34–14:44: project was already reported as RESTARTING. One official project-restart request was accepted with HTTP 200, but the project did not recover. Restart-state observations now span more than 13 hours.
• October 26: organization upgraded to Pro; authenticated urgent production-down support requests submitted, citing the original case.
• October 26, 19:41: a human support response confirmed the stuck restart and said it was being escalated to infra-compute.
• October 26, 23:55: we replied in the same thread asking for an ETA, a specific next-update time, confirmation of active engineering work, and preservation of data/Vault.
• As of the latest check: no further technical response, recovery ETA or definitive solution.

Existing support cases

Original: SU-524888. Related Pro requests: SU-525840 and SU-525978. We have asked support to link the cases. Please use these existing cases rather than creating another disconnected support loop.

Recovery constraints and requested action

We have not run repeated restart loops, paused/deleted the project, restored an old backup over it, or changed encryption keys during this outage intervention. We have an independently restored October 24 backup, but it is older than the outage and is not proof that subsequent changes can be discarded.

We need:

1. Confirmation that an infra-compute engineer is actively investigating, with a case owner.
2. A recovery ETA, or a specific UTC time for the next substantive update if an ETA is not yet possible.
3. Recovery of the existing instance while preserving current database/Auth/Storage data and Vault secrets, ciphertext and root-key configuration. Please coordinate any step that could alter data or encryption first.
4. If the original instance cannot be recovered promptly, a supported route to restore/migrate into a separate project while preserving Vault and leaving the original project intact for reconciliation.

Our fallback decision point is October 27, 15:00 UTC (09:00 Mexico City) if there is no measurable improvement or definitive solution. We are preparing that option; migration has not started.

We understand community forums cannot inspect private projects. This post asks for incident visibility and an actionable official response through the existing cases. We are not posting credentials, keys, tokens, private logs, backups or user data. The underlying cause is still unconfirmed.

[shawniwe]

Hope you're back up by now. If you ended up restoring from the Oct 24 backup or moving to a new project, a few things are easy to miss and worth checking:

• Data gap: rows, auth users and Storage objects created between Oct 24 and the outage. If the old project comes back even read-only, diff auth.users / auth.identities and your main tables by created_at and backfill - new users from that window otherwise can't log in or end up with a second account.
• Vault and Edge Functions secrets don't come with a plain pg_dump restore. Re-create them and rotate anything that was only stored in the old project.
• Sequences: after a data-only restore, run setval on serial/identity columns or the next inserts fail with duplicate keys.
• Storage: objects live outside the DB dump, so the storage.objects rows and the actual files can drift. Worth a quick count comparison per bucket.

For next time, the cheapest insurance we've seen is an independent nightly pg_dump (plus a Storage sync) from a scheduled GitHub Action to your own S3 bucket, and a written runbook for "bring the app up on a fresh project". That turns a 26-hour outage into a ~1-hour switch.

If it helps, happy to review your restore or set up that backup + failover runbook - we help teams running production apps on Supabase. Either way, glad to share the Action we use.