Is Supabase down, or is it your app? How to tell

Your app opens, and then nothing loads. The list that should show your customers' orders is empty, the sign-in button spins, or the page stays white. Somebody has already messaged you about it. So you search "is Supabase down", because your app was built with Lovable or Bolt on top of a Supabase project, and Supabase is the only part of the machinery you know by name.

Here is where the usual answer goes wrong. It says: check Supabase's status page. That is the right first move, and it answers one question out of four. Your project stops answering your app when Supabase has an outage, and also when Supabase has paused it, when it has hit a limit, and when your own app is broken while Supabase answers every request correctly. Your customer sees the same blank screen in all four cases, and the status page knows about the first.

Think of it as the lights going out at home. The first thing anyone does is look out of the window to see whether the neighbours are dark too. That is the status page, and it tells you about the street. It says nothing about the letter on the doormat, the fuse box in the hall, or the bulb.

Every Supabase page, incident and figure below was read on 30 September 2026.

Is Supabase down, or is it your app?

You cannot tell from the screen, which is why the search leaves people stuck. Four different failures produce the same result:

1. Supabase is down. Something on Supabase's side has failed, usually in one region or one service. The street has gone dark.
2. Your project is paused. Supabase stops free projects that have had no activity for about a week. Your supply has been disconnected, and nobody else on the street is affected.
3. Your project has hit a limit. It filled its space and went read-only, or ran short of capacity and slowed until requests timed out, or your organization went over a quota and was restricted. A breaker has tripped.
4. Your app is broken. Supabase is answering, and something on your side, a key, a table's access rules or a piece of code, turns that answer into a blank screen. The power is fine. It is the bulb.

Your project, here and below, means the Supabase database your app keeps its data in, together with the sign-in, file storage and API around it.

The checks below take them in order, cheapest first, and each one rules a failure in or out.

Four checks, cheapest first

Step 1: is Supabase down for everyone?

Open status.supabase.com. If an open incident names your region or a service your app uses, you have your answer, and the section on outages further down is what to do with it.

The page lists Supabase's services one at a time: the database and the API your app reads it through, Auth for sign-in, Storage for uploaded files, Realtime, Edge Functions, the dashboard and a few more. Below them is a list of regions. A region is the part of the world your project runs in, and yours is shown on the project's Infrastructure settings page, with a code such as eu-west-1. An incident in us-east-1 has nothing to do with a project in Ireland, so find your code before you read anything else.

What the page does not have is a row for your project. It reports problems that affect enough projects to announce, and real incidents are often narrow. The fifty most recent on it, running back to 15 July 2026, include one that took down only the projects on one set of hardware in eu-west-1, one that left projects on the smallest, free-plan size unresponsive after a few hours of running, and one about 401 errors on a subset of new projects that stayed open for 46 days.

So a green page tells you Supabase has not announced a problem. Your project can be down underneath it, and the next three checks are about that.

The dashboard has a row and incidents of its own. On 1 September 2026 people could not log in to it at all, and an app can keep running through one of those.

While you are on the page, subscribe to updates. It takes an email address, and Supabase also publishes the incident history as an RSS feed.

Step 2: is your project paused?

Open the Supabase dashboard and look at your list of projects. A project with Paused beside its name was stopped by Supabase, most often a free project that went about a week without activity, and it stays stopped until you resume it. Everything else about a pause, including the one-year deadline and what to do once the option to resume has gone, is in what to do when your Supabase project is paused.

Step 3: has your project hit a limit?

Look at what still works. Each limit breaks something different, and the pattern tells you which one has tripped.

Pages load and nothing saves. That is read-only mode. A free project goes read-only when its database passes 500 MB, and a paid one when its disk fills faster than Supabase is allowed to grow it. Reading still works, so the app looks fine until somebody tries to sign up, place an order or save a form, and every write comes back with cannot execute INSERT in a read-only transaction. The way out is more space, by upgrading or by deleting data. What each free-plan limit switches off covers both, and Supabase's database size guide has the SQL.

Everything slows down, then stops answering. The project has run out of headroom. Its compute size sets how much memory it has and how hard it can work its disk, and the smaller sizes get a daily allowance for bursting above that, which Supabase calls the Disk IO Budget. Once it is spent, Supabase's own list of what can follow includes response times that rise noticeably and an instance that becomes unresponsive. The budget refills the next day, and the Database Health page under Observability shows where you stand.

You may get an email saying the project "is running out of Disk IO Budget", or see a notice in the dashboard that it is unhealthy, with a Restart project button under it. Read the email as a clue. After an incident on 10 September 2026, Supabase told the owners caught up in it that the Disk IO email they had received was no longer valid: the incident had caused it.

Every request fails with a 402. Your organization has been restricted under Supabase's Fair Use Policy, for staying over a quota after its grace period or for an unpaid bill, and the restriction usually covers every project in the organization. The 402 names the reason with a code such as exceed_db_size_quota or overdue_payment, and Supabase says you can still reach your data through the dashboard while it lasts. Upgrading lifts a usage restriction at once; otherwise it lifts when the next billing cycle starts.

This is the fuse box. All three happen inside your own project, so the status page shows none of them.

Step 4: ask your project directly

Send it one request and read the answer. If Supabase answers normally, the fault is on your side of the connection.

The quickest version needs no tools. Your project's address looks like https://abcdefghijklmnopqrst.supabase.co, and the string of letters before .supabase.co is in your browser's address bar whenever the project is open in the dashboard. Put /rest/v1/ on the end, paste it into a new tab and look at what comes back.

• A line of text in curly brackets saying no API key was found. Supabase is answering at your project's address. It turned you away because the tab sent no key, which is correct. The project exists and it is not paused.
• "This site can't be reached", or "server not found". The address does not resolve. Supabase's troubleshooting page for that error names the usual reasons: a paused project, a deleted one, or a mistyped address.
• An error page with a number in the 500s, or nothing after a long wait. The address exists and the project behind it is struggling. Go back to step 3, and look at the status page again.

The fuller version is your browser's Network tab, which shows the answers your app is getting with its own key attached. Open your app, press F12, choose Network, reload the page, and type the letters from your project's address into the filter box. Every request to your project appears with a status code, and the code is most of the diagnosis. The meanings below are from Supabase's list of status codes and the database API it runs:

The row to look for first is 200. If your app's requests to Supabase come back 200 and the screen is still blank, Supabase has done its part, and the bulb is yours. A table's rules may be letting this visitor see no rows, which arrives as a 200 carrying an empty list. The app may be pointed at a different project from the one you are looking at. Or the code that draws the page broke on what it was given, which is a question for your builder, with the request and its answer in hand.

Why am I suddenly getting 401 errors from Supabase?

Because Supabase answered and refused who was asking. A 401 means the request reached your project, so the platform is up. What it rejected is one of three things, and the message says which: click the request in the Network tab and open its Response.

• The key. The message says Invalid API key or Legacy API keys are disabled. Your app is sending a key the project no longer accepts. The older anon key, a long string beginning eyJ, stops working when someone switches the legacy keys off in the project's settings, and Supabase has warned that a paused project restored since 1 November 2025 comes back without it: in its own words, "paused projects that are restored risk being broken as they won't have the legacy keys". The fix is the project's current publishable key, which begins sb_publishable_, in your builder's environment settings. The two key formats are compared side by side.
• The table. The message says permission denied for table. The key is fine, and that table has not been opened to this kind of visitor. From 30 October 2026 a new Supabase table starts out that way, and the safe way to open it has an article of its own.
• The session. Signed-out pages work, signed-in people get 401s that come and go, and the message usually mentions a JWT, the signed token your app holds for each person who is signed in. From 14 August to 29 September 2026 Supabase's status page carried an incident titled "401 errors due to JWT rejections": a subset of new projects rejected sessions that had just been renewed. Supabase's fix, released on 29 September, is a new version of the project that you install yourself, with the Upgrade project button on the project's General settings page.

That upgrade takes the project offline while it runs, and the dashboard shows an estimate of how long before you confirm. Supabase's upgrade guide recommends taking a copy of your data first. On the free plan nobody else is taking one, and making one from the dashboard needs no terminal.

How do I restart a Supabase project?

In the dashboard: open the project, go to Project Settings, then General, and press Restart project under Project availability. The arrow beside the button offers Fast database reboot, which restarts the database alone and keeps the downtime shorter. Either way, Supabase warns of a few minutes offline.

A restart is the right tool for a project that is overloaded or marked unhealthy, and it is what Supabase asked affected owners to do after the 10 September incident. If the project is too small for its work the trouble comes back, and the lasting fix is a larger compute size or lighter queries. A paused project needs Resume project, which sits in the same place. A full database is still full after a restart, and a refused key is still refused.

Leave the button alone during an incident that names project actions. On 4 September 2026 restarts, restores and compute changes were erroring in every region, Supabase asked people not to attempt them, and for a while it switched them off altogether.

What can you do during a Supabase outage?

Very little, and waiting is the right call. The outage is Supabase's to fix, and your project comes back without you touching it.

That makes an outage the one failure in this article that waiting solves, and it is why step 2 comes before anything you do here. You wait out a power cut. A disconnection stays in place until you call the supplier, and a paused project stays down until you resume it, with a year on the clock from the day it stopped.

What is worth doing while you wait:

• Confirm it is yours. Check the incident names your region, or a service your app uses.
• Subscribe to that incident, so the update that says it is over reaches you.
• Tell your users. One line wherever they will look for you, saying the app is affected by an outage at its database provider and will be back.
• Leave the project alone. During the 4 September incident Supabase's advice was "against taking any of these actions until this incident is resolved: Creates, Configuration changes, Restarts, or Compute size changes". Running projects kept running while those actions failed.

There is also nothing to claim for the downtime unless you are on Enterprise. Supabase's uptime commitment, with service credits for a month under 99.9%, is written for Enterprise customers alone.

What to have in place before the next one

Four things, all of them easier on a day when nothing is wrong:

• Your region, written down beside your project's address, and a subscription to the status page.
• Your app on the publishable key. Supabase is retiring the legacy anon and service_role keys by the end of 2026, and an app still sending one will start collecting 401s when they go.
• A copy of your database outside your Supabase account. An outage, a pause and a restriction all happen inside Supabase, and a copy kept elsewhere is out of their reach. On the free plan Supabase keeps no copy for you.
• Something that notices when your app stops answering and tells you before a customer has to.

Where Reeve fits

Reeve Monitor watches the address your visitors load. Reeve Care also connects to the Supabase database behind it, and keeps a copy of it outside your Supabase account.

• Monitor checks your app's address every 60 seconds from outside, and emails you once when it stops answering and once when it is back. It also re-runs all nine of our security checks every hour, on up to three apps.
• Care connects to your Supabase database itself to take a copy, daily on Care and more often on the plans above it. A night the database does not answer is a copy that could not be taken, and you get an email saying what happened.
• The copy lives outside your Supabase account, encrypted, and it is read back before it counts, so a pause or a restriction leaves your last good copy where you can reach it.
• Restoring is a button, and it takes a snapshot of the current state first, so the restore has an undo of its own.

What each plan covers is on the pricing page, and the copy, the check and the restore are drawn step by step on the Supabase backups page.

What to do now

Before you close this tab, open your project's Infrastructure settings, write its region code down next to its address, and subscribe to the status page. If today's blank screen turned out to be a pause, here is what to do next.