---
title: "What happens to your app when Supabase has a bad day"
description: "Why a Supabase outage makes your app look perfect and empty, how to check in three minutes, and what to do while you wait."
url: https://www.fomio.ai/blog/what-happens-to-your-app-when-supabase-has-a-bad-day
published: 2026-09-14T18:00:00.329+00:00
updated: 2026-09-14T18:00:00.329+00:00
topic: supabase
words: 1937
---

# What happens to your app when Supabase has a bad day

Your screens load, the data doesn't, and nothing looks broken — here's how to tell whose problem it actually is.

**In short:**

- Your screens and buttons live somewhere else, so they keep loading — it's the part that remembers things that stops answering.
- Outages are usually regional, so your project may be fine while someone else's is dark.
- Login fails first, then reading data, then saving, then images.
- Most "it's down" moments are something you shipped in the last hour, which is the good outcome.
- Knowing your project's region turns the next outage into a thirty-second check.

### What happens to my app when Supabase goes down?

Your app still loads, because the screens and buttons are files sitting elsewhere. What stops is everything underneath: the database holding your users' data, the login system, file storage and live updates. So people see a normal-looking app that is completely empty, spins forever, or quietly fails to save what they typed.

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.[^1]

- **3 hours 42 minutes** — How long every service in one US region was unavailable on 12 February 2026 [^1]
- **Under 5%** — Share of customers affected by that outage [^2]

## 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.[^2] 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.[^1]

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.[^3]

## How do I tell whose problem it is?

1. **Open the status page** — Go to [status.supabase.com](https://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. **Try your own dashboard** — If the dashboard itself won't load, it's them, not you.
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. **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.

> **Unreachable is not lost** — Your data is almost certainly fine. Being unable to reach a database and losing what's in it are very different events, and outages of this kind are the first one.

## 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.[^5]

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.[^4]

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.

*Four ways to hear about it first, and what each one actually watches*

| Option | What it watches | How it tells you | Best for |
| --- | --- | --- | --- |
| Supabase's own status page | Incidents Supabase has noticed and acknowledged | Email, if you subscribe | Free, official, silent about your app |
| Status aggregators (StatusGator, IncidentHub, Pulsetic) | The official status pages of many services at once | Alerts around the time a notice is posted | Apps leaning on several services |
| Uptime checkers (UptimeRobot, Better Stack, Pingdom, Cronitor) | Your actual site, loaded from outside on a schedule | Email, text, phone | People comfortable configuring it |
| Fomio | Your actual app, from outside, with nothing to configure | Email | People who didn't choose this stack |

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.

**Paste this into your AI tool**

```text
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.

## Questions people also ask


### Will I lose data during an outage?

Almost certainly not. In this kind of outage the database is unreachable rather than damaged — it's sitting there, refusing to answer. What you can lose is anything a user typed into a form while it was down, because that never arrived anywhere. That's the real argument for showing an honest failure message instead of letting a form pretend it saved.

### The status page is green but my app is empty. Now what?

Then it's probably you, and that's the fixable outcome. Check whether a free project has gone to sleep after inactivity — that looks identical to an outage from outside and wakes up with one click. Then look at whatever you shipped most recently. Changes to permissions rules, login settings or the shape of your data break an app in exactly the same silent way.

### Can I move my project to a different region to avoid this?

Moving doesn't remove the risk, it relocates it. Every region can have a bad day, and the February 2026 incident happened to land on one US region while everywhere else carried on normally. The useful move is knowing which region you're in, so that when an incident is posted you can tell in seconds whether it concerns you at all.

### Should I tell my users, or wait and hope nobody notices?

Tell them. A single line — your data provider is having an outage, you're watching it, nothing is lost — costs you two minutes and buys an enormous amount of patience. Silence is what turns a three-hour outage into cancelled accounts. Post it somewhere they'll actually look, and post again when it's over.

### Is a free status page enough, or do I need something watching my app?

A status page only tells you about the vendor, and only once they've noticed. It says nothing when your app breaks for one of the many other reasons apps break — a bad deploy, an expired key, a permissions rule you changed. Something checking your app from outside covers both cases, because it's looking at what your users are looking at.


## Sources

[^1]: Supabase incident on February 12, 2026 — Supabase (2026-02-13). https://supabase.com/blog/supabase-incident-on-february-12-2026
[^2]: Supabase Outage on February 12, 2026: What Caused the 3-Hour Service Disruption — AdwaitX (2026-02-15). https://www.adwaitx.com/supabase-outage-february-12-2026-incident/
[^3]: Supabase Status — Supabase. https://status.supabase.com/
[^4]: Supabase Status — Incident History — Supabase. https://status.supabase.com/history
[^5]: Is Supabase Down? Supabase Status & Outage Tracker — Pulsetic. https://pulsetic.com/status/supabase/
[^6]: Is Supabase Down Right Now? Live Status and Outage Checker — IncidentHub. https://incidenthub.cloud/status/supabase
[^7]: Supabase Status — StatusGator. https://statusgator.com/services/supabase