What happens to your app when Supabase has a bad day

Your app is still there. That's the first thing worth knowing, because it really doesn't feel like it.

When the service behind your app has a bad day, your users usually don't see an error page. They see your app, loading perfectly, looking completely normal — and then nothing. The login button spins. The list that should be full of their stuff is empty. A form says it saved and didn't.

That split is the whole story, and it's why this is so confusing the first time it happens to you.

Why does my app still load if the database is down?

The part you built — screens, buttons, layout, copy — is sitting on whatever service your builder deploys to. It's a set of files. Files don't really break.

Supabase is everything underneath that. The database that holds your users and their data. The login system that decides who someone is. The file storage where uploads and images live. The bits of custom code that run on their machines rather than in the browser. Live updates, if your app uses them.

So when that layer is unavailable, the shell of your app loads fine and the inside of it is hollow. That's why you get a beautiful, empty app instead of an honest error message.

Supabase's own write-up of their February 2026 outage lists exactly this set of things going at once. A change they deployed knocked out every service in one of their US regions, and customers there couldn't reach their databases, their login system, their data, their custom code, their file storage, or live updates.¹

What will my users actually see during an outage?

There's a rough order to it, and knowing the order saves you ten minutes of panic. Things fail in the sequence your app touches them.

• Login goes first. New people can't sign up, existing people can't sign in. People already signed in on a phone often stay signed in for a while — which is why one user swears the app is broken and another swears it's fine.
• Then reading data. Lists, dashboards, profiles. These usually come back empty rather than erroring, or hang on a loading state forever.
• Then writing data. Forms submit into nothing. This is the worst one, because your user believes the thing saved. It didn't.
• Then images and uploads. Avatars, documents, photos — broken or blank.

A write-up of the February incident by AdwaitX described the practical shape of it: shops couldn't take payments, apps couldn't sign anyone in, and anything collaborative went quiet.² That's not an exotic failure. That's just what an app is without its database.

Is Supabase down, or is it just my project?

Usually it's a piece of it, in one region. When you created your project you picked a region — or your builder picked one and you clicked past it. Ohio, Frankfurt, Singapore, somewhere.

That choice matters more than it looked. February's outage was regional. If your project sat in that region, your app was dark for nearly four hours. If it sat anywhere else, you had a normal evening and never knew.¹

It cuts the other way too. If the status page is all green, that does not prove your app is fine. It might be your app.³

How do I tell whose problem it is?

1. 1
   Open the status page

   Go to status.supabase.com and look for your region by name, not just the colour at the top. If your region is named in an open incident, you have your answer and there's nothing to fix.
2. 2
   Try your own dashboard

   If the dashboard itself won't load, it's them, not you.
3. 3
   Check whether your project is asleep

   Free projects go to sleep after a stretch of inactivity, and a sleeping project looks identical to an outage from the outside. This one you fix yourself, in a click, from the dashboard.
4. 4
   Ask what you changed

   If you shipped something in the last hour, suspect that first. A change to your data, your permissions rules or your login settings breaks an app exactly the same way an outage does.

Most "it's down" moments are actually number four. That isn't a criticism — it's good news, because number four is the only one you can fix.

What should I do if it really is them?

You wait. You cannot fix someone else's region, and there's no setting on your side that helps. The useful things left are all about your users, not your database.

• Tell people something. A line on your homepage: "Our data provider is having an outage, we're watching it, nothing is lost." People forgive downtime. They don't forgive silence.
• Subscribe to the incident itself on the status page, so you find out it's over without refreshing all evening.
• Don't start fixing things. You'll ship a real bug into a broken app, and then you'll have two problems you can't tell apart.

How often does this actually happen?

Often enough to prepare for, not often enough to move off. Third-party trackers that watch the official status page — Pulsetic is one — log dozens of incidents over a rolling 90-day window, a minority of them classed as major, with a typical one resolved inside a couple of hours.⁵

Most of those are small: slow dashboards, delayed logs, one piece of plumbing in one region misbehaving. The four-hour, everything-in-a-region kind is rare and gets a public write-up when it happens.⁴

The practical read: several times a year, something will affect somebody. The odds it's you, in your region, on any given day are low. The cost of finding out from an angry customer is high.

How do I find out before my users do?

There are four reasonable options, and they answer slightly different questions. Two tell you about the vendor. Two tell you about your app.

The classic uptime checkers are mature and thorough. They check from many places around the world, keep long histories, and can ring your phone. They were also built for engineers, and the setup asks accordingly — which addresses, how often, which replies count as healthy, where to route the alert. The message at 3am assumes you can read it.

Fomio does the same watching from outside and is built for the person who didn't choose this stack. You paste a link, it works out what to watch, and there's nothing to set up. It reports one of three things: Working, Having trouble, or Down. When something breaks it says in plain language what likely went wrong, and on the paid plans it writes a prompt you can paste straight into the tool you built with.

Where the others are genuinely better: more locations to check from, longer records, and they'll call you. Fomio tells you by email only. The free plan watches one app, checks every five minutes, emails you when it breaks and keeps a week of history, with no card. Builder watches three, checks every minute and writes those fix prompts. Pro watches fifteen, keeps a year of history and gives your users a status page. Current prices are at fomio.ai/pricing.

My app loads its screens fine but fails when the database is unreachable, and users just see empty lists and spinning buttons. Add clear handling: when a data request fails or times out, show a short message saying the app can't reach its data right now and to try again in a few minutes, instead of an empty state. Do the same for sign-in and for any form submission, and make sure a failed save never shows a success message.

What should I do this week?

Look up which region your project is in and write it down somewhere you'll find it at midnight. That one fact turns the next outage from a mystery into a thirty-second check.

Then put something in place that watches your app from the outside, so the news reaches you before it reaches your users. The status page is free and it's better than nothing. If you'd rather be told in words you don't have to decode, that's the job Fomio was built for, and the free plan costs nothing to try.