Free Plan Project Stuck in "Unhealthy" State - Database Crashed Due to "No space left on device" (pg_wal) - Cannot Restart or Pause

[axiruzgar]

Project ID: wmiujmxszbbtbnhfgceeProject Name: cbm-systemRegion: Central EU (Frankfurt) / eu-central-1Plan: FreeCompute: Nano

Hello Supabase Community,
I'm posting here because my project has been stuck in an unrecoverable state for over 24 hours, and I'm hoping someone from the team or community can help me understand what's happening.
🔴 The Problem
My project is currently showing "Unhealthy" status in the dashboard, with the following health check error:
text
Database not usable
Connection failed at the TCP layer (ECONNREFUSED) after 22ms: connect ECONNREFUSED 2a05:d014:1577:8801:451a:f801:132:f9ce:5432

📉 Timeline of Events
Sep 21, 10:53 GMT+3: Last successful GitHub Actions backup run (47 seconds).
Sep 23, 09:47 GMT+3: First "No space left on device" errors appear in logs.
Sep 23, 09:51 GMT+3: Database crashes and begins a restart loop.
Sep 23, 17:59 – 18:53 GMT+3: Database is in "recovery mode" and "not accepting connections" (57P03) repeatedly. API Gateway returns 504 and 522 errors.
Current: Project remains Unhealthy. All connection attempts fail with ECONNREFUSED.
📋 Key Error Logs
text
53100 could not write to file "pg_wal/xlogtemp.14567": No space left on device
53100 could not write to file "pg_wal/xlogtemp.13277": No space left on device
57P03 the database system is in recovery mode
57P03 the database system is not accepting connections
57P03 the database system is starting up

🚫 What I've Tried (Unsuccessfully)
Restart project (from Project Settings > General) — No change. Project remains Unhealthy.
Pause project — Returns the error: Failed to pause project: Failed to verify backup status before pausing.
SQL Editor / Table Editor — Both fail with connect ECONNREFUSED.
Network bans list — I cannot fully access or view this list because the API call (/admin/v1/network-bans/retrieve) returns 522.
Disabled the GitHub Actions backup workflow — I have disabled db-backup.yml to prevent further connection attempts.
📊 Usage Data (Free Plan)
According to the Organization Usage page, all metrics are at 0 or <1%:
Database Size: 0 / 500 MB
Storage Size: 0 / 1 GB
Egress: 0 / 5 GB
Monthly Active Users: 0
Edge Function Invocations: 0
This suggests that the logical data size is minimal, but the physical disk (likely pg_wal) is full.
❓ My Questions
Has anyone else experienced this exact "disk-full WAL crash loop" on the Free plan?
Is there any way for me to clear the pg_wal directory or drop a stuck replication slot without direct database access?
Does disabling the GitHub Actions backup guarantee that the disk will eventually free up, or does this require manual intervention from the Supabase infrastructure team?
If this requires support, what is the best way to escalate this on a Free plan? I have already opened a ticket but have not received a response yet.
🙏 Request
I understand this is a Free plan, but my project is completely inaccessible and I cannot recover it from the dashboard. Any guidance on how to proceed — or confirmation that this requires backend intervention — would be greatly appreciated.
Thank you for your time.

[GaryAustin1]

Support will need to help or in most case upgrading to Pro withe more disk space or then the included micro instance with more resources resolves it.

This seems to occur after an SQL request that is too compute/disk intensive for a nano project.

[alpsten]

This looks like a WAL retention issue rather than actual data growth. Your usage page showing about 0MB while pg_wal fills the disk is the classic signature of a stuck/inactive replication slot holding WAL segments indefinitely, rather than a genuine storage overage. Since you can't reach the DB at all (ECONNREFUSED) and pause also fails, this isn't something fixable from the client side. The fix (dropping the stuck slot or freeing disk) has to happen at the infra level.

You can try these things as well, if you have not already done so:

• Double-check what your GitHub Actions backup workflow actually did. If it opened a logical replication connection or created a replication slot (rather than a plain pg_dump?), and that slot was never dropped, that's very likely your root cause.
• File a support ticket through the dashboard (Support > new ticket, mark it as an incident/project down). This is an infra-level problem (unresponsive project), and Supabase does prioritize "project completely down" tickets even on Free plan, separately from usage-limit tickets.
• Reference this discussion and your project ref (wmiujmxszbbtbnhfgcee) in the ticket so support can go straight to checking replication slots / disk on the host.

Unfortunately there is no self-service recovery path once the DB won't accept any connections. This needs someone on the Supabase team to intervene on the host.

Good luck!

[dfbustosus]

The logs prove a disk-full failure, but not its root cause. PostgreSQL defines 53100 as disk_full and 57P03 as cannot_connect_now; the pg_wal/xlogtemp... errors show that WAL could not be written because the volume had no free space.

The reported 0 MB database size does not prove a stuck replication slot. Supabase distinguishes logical database size from total disk usage, which also includes WAL and system files, and those metrics are updated daily. A retained replication slot is possible, but it remains a hypothesis until inspected. If the backup workflow only ran ordinary pg_dump, it did not create a logical replication slot by itself, so disabling that workflow does not guarantee existing WAL will be released.

While the database refuses all connections, you cannot inspect or drop slots through SQL. Do not manually delete pg_wal files. If the database becomes reachable, use Supabase's official replication-slot monitoring query and only drop a slot after confirming that no consumer still needs it.

There is also a self-service recovery path the other answers have not mentioned: if the September 21 backup artifact is valid and complete, create a new project and restore it using Supabase's backup and restore guide.

Test and validate the restored project before switching over or deleting the old one. The backup may omit roughly 47 hours of database changes between its snapshot and the crash. Its coverage also depends on the commands used by the workflow: Storage object files and Edge Functions require separate migration, while project, Auth, API, and Realtime settings may need reconfiguration. If Vault or pgsodium was used, follow the guide's encryption-key instructions before removing the old project.

Keep the existing support ticket open for recovery of the original project. Supabase's published support policy limits guaranteed technical support to paid resources and says staff participation in community channels is discretionary; it does not document priority handling for down Free projects.