Disk IO issue

[asitaaa]

I got an email saying that one of my db (on the free plan) is unhealthy. I'm surprised, as I'm not using it at all. How do I turn it off without deleting it?

[NextTyrCreator]

You don't need to delete it. Pause it.

On the free plan the project keeps running until its paused or it auto pauses after some time without activity. You can still have code running thats exhausting the existing budget until its paused.

You can delete it from the same menu that you'd pause it from but if you plan on needed it or the data is valuable; my recommendation would be to pause it from the Settings → General → Project availability section and "Pause project". You can restart it later this way as well. It will typically never pause if you have something running in the background keeping the operation alive though.

[asitaaa]

I'm trying to pause it, but it won't let me. I click the pause button, and I assume it should disable after I click it since the project is paused. It doesn't.

[CarolMonroe22]

hey! two things going on here:

why it's "unhealthy" if you're not using it: the free instance has a small Disk IO budget, and once it's used up the database drops to its baseline speed, which triggers that email. usually something is still hitting it in the background, like an old deployed app or bot, a pg_cron job, or an open tab with realtime subscriptions. worth a quick look at the logs to see what's connecting.

about the pause button: supabase had a project lifecycle incident in eu-west-1 earlier today (resolved around 17:38 UTC), which affected exactly these operations. if your project is in that region, hard refresh the dashboard and try again now. after you click it, the project should show "Pausing" for a few minutes.

if the button still does nothing, you can pause it via the Management API with a personal access token (dashboard > account > access tokens):

curl -X POST https://api.supabase.com/v1/projects/YOUR_PROJECT_REF/pause -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

docs: https://supabase.com/docs/reference/api/v1-pause-a-project

[asitaaa]

Here's one of the entries in the log.

{
"id": "008cdd3e-3afc-41d5-b24a-754e101ed7b2",
"date": "2026-09-24T20:54:42.189Z",
"method": "POST",
"pathname": "/admin/v1/network-bans/retrieve",
"status": "522",
"timestamp": "2026-09-24T20:54:42.189000",
"level": "error",
"event_message": "POST | 522 | https://pfwatxlepjgqabosokyp.supabase.co/admin/v1/network-bans/retrieve | @supabase-infra/mgmt-api/v1.355.5",
"log_type": "edge",
"log_count": null,
"logs": [],
"auth_user": null
}
I have no clue how to analyze it.

[CarolMonroe22]

that entry actually isn't your app D: or anyone connecting. it's supabase's own management API (the dashboard) trying to reach your project, and 522 means it timed out. so the database is too stuck to answer, which also explains why the pause button does nothing: the pause can't go through while the instance isn't responding.

what i'd try, in this order:

1. Settings > General > Restart project. give it a few minutes to come back healthy.
2. once it's up, pause it right away from the same page.
3. if the buttons still don't respond, use the API call from my previous comment. github ate the placeholders in my command, here it is again:

curl -X POST https://api.supabase.com/v1/projects/YOUR_PROJECT_REF/pause -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

if none of that works, open a ticket from the dashboard (Support in the top bar) with your project ref, and mention the 522s on the management API. at that point it needs someone on their side to unstick it.

[somuai]

What the Log Entry Means

The log entry you posted:

{
  "method": "POST",
  "pathname": "/admin/v1/network-bans/retrieve",
  "status": "522",
  "event_message": "POST | 522 | https://pfwatxlepjgqabosokyp.supabase.co/admin/v1/network-bans/retrieve | @supabase-infra/mgmt-api/v1.355.5",
  "log_type": "edge"
}

Here is the exact breakdown:

1. The Endpoint (/admin/v1/network-bans/retrieve):
   This is not user traffic or an external attacker. It is an internal administrative polling request dispatched by the Supabase Management control plane (@supabase-infra/mgmt-api) to your project's edge gateway (Kong/Envoy). It periodically retrieves active IP network bans / rate-limit blocks from fail2ban on your instance.

2. The Status Code (HTTP 522):
   HTTP 522 is a Cloudflare / edge proxy "Connection Timed Out" error. The edge router initiated a TCP handshake with your project's underlying virtual machine / container, but the host did not complete the handshake before the TCP timeout window expired.

---

Why the Host Timed Out and the "Pause" Button Fails

This behavior is a direct consequence of Disk IO Budget Exhaustion:

1. Disk IO Throttling: Free Plan (Nano compute) instances use shared AWS EBS storage with a burstable IOPS balance. When the burst credit pool drops to 0%, the underlying storage volume is throttled to its baseline throughput (as low as 100–300 IOPS / minimal MB/s).
2. Kernel D-State (Uninterruptible Sleep): Under extreme IO starvation, PostgreSQL processes and system daemons become trapped in Linux D state (uninterruptible disk sleep waiting for fsync / block writes). Because the internal admin daemon cannot read or write to disk, its socket listener stalls, resulting in the HTTP 522 timeout you see in the logs.
3. Why "Pause" Fails: When you click "Pause Project" in the Dashboard, the Supabase control plane attempts to verify database state and initiate a graceful pg_ctl stop and container shutdown. Because the host's admin daemon is timing out (522), the pause orchestration fails pre-flight validation and silently aborts.

---

Step-by-Step Resolution Runbook

To break the deadlock and pause the database without deleting it:

Step 1: Force a Host Restart Instead of Pause

A restart bypasses the graceful API handshake and issues an instance-level reboot, which terminates stalled D-state processes and replenishes an initial burst window:

1. In the Supabase Dashboard, go to Project Settings -> General.
2. Scroll to Restart project.
3. Select Fast reboot (or restart).
4. Wait 2–3 minutes for the project status to return to Healthy or Active.

Step 2: Immediately Pause the Project

The moment the project finishes rebooting and becomes responsive:

1. Go to Project Settings -> General -> Project availability.
2. Click Pause project.
3. Initiating pause right after reboot succeeds because the instance has not yet had time to exhaust its fresh IO burst credits.

Alternative via Management API if the UI hangs:

curl -X POST "https://api.supabase.com/v1/projects/pfwatxlepjgqabosokyp/pause" \
  -H "Authorization: Bearer <PERSONAL_ACCESS_TOKEN>"

Step 3: Identify What Was Consuming Disk IO (If You Re-open It)

If you are not actively sending traffic from your frontend, the most frequent causes of background Disk IO exhaustion on dormant projects are:

• Active pg_cron jobs: Check SELECT * FROM cron.job; for jobs running on tight intervals (* * * * *).
• Realtime publication overhead: Tables with frequent updates or large payloads published to supabase_realtime without primary keys.
• Autovacuum thrashing: Autovacuum repeatedly attempting to clean bloated temporary tables or unindexed foreign keys under low memory.
• Client reconnection storm: An old frontend deployment or local dev server left running that hammers /rest/v1/ in an infinite loop after receiving errors.

[asitaaa]

That worked. thx. I restarted, waited a bit for the healthy status, and then I could pause it.