Is Firebase down? How to tell, and what to do next

The fastest answer is the Firebase status page on isuptime, which reads Firebase's own feed every few minutes and says what it currently reports.

The more useful answer starts with a structural point: Firebase's status page is not the same kind of document as most of the others on this site. There is no live grid of components each showing a coloured dot. There is a log of incidents, opened and closed by product, and very often scoped to a region. Green does not mean "everything is verified healthy". It means "no incident is currently open".

What Firebase actually reports on

Incidents are filed per product. The ones that appear in its history:

Product	What breaks when it does
Realtime Database	Reads and writes stall or fail — usually in specific regions
Hosting and App Hosting	Sites stop serving, or domain onboarding stalls
Cloud Messaging	Push notifications are delayed or dropped
Crashlytics	Crash reports stop arriving — your app is fine, your visibility is not
Performance Monitoring	Traces and dashboards go stale
Remote Config	Clients keep the last config they fetched
App Distribution	Test builds will not distribute
A/B Testing, Test Lab, SQL Connect, AI Logic, Studio	Their own scoped failures
Multiple Products	The label Google uses when the cause is underneath several of them at once

That last row is the one to watch. "Multiple Products" is Firebase saying the problem is lower down the stack than any single product — and Firebase runs on Google Cloud, which has its own status page and its own incidents.

Region is the first question, not the last

Firebase's incident history reads like this: "A small subset of databases in asia-southeast1 experienced service outage." "Unable to create or open workspaces in Asia."

Your project lives in a region. An incident in a region you do not use is not your incident, and an aggregate indicator that goes amber will not make that distinction for you. Before doing anything else during a Firebase incident, read which region — it resolves a good half of them immediately.

The corollary is less comfortable: a genuine, severe, hours-long Firebase outage in someone else's region is invisible to you, and yours is invisible to them. Two engineers can look at the same status page in the same minute and both be reading it correctly with opposite conclusions.

The failure Firebase will never post

Firebase is unusual in how much of its failure surface is configuration rather than infrastructure. Four things break constantly, none of them are outages, and none of them will ever appear on a status page:

1. Security rules. A rules deploy that denies a read produces a permission error at the client, indistinguishable from "the database is broken" to anyone reading a support ticket. This is the single most common cause of "Firestore is down" that is not Firestore being down.

2. Quota and billing. Free-tier limits and spend caps stop service cleanly. So does a payment method that expired quietly. The service is up; your project is not being served.

3. App Check and auth configuration. A misconfigured attestation provider, an expired certificate, a domain not on the allow-list — all of these reject traffic that looks perfectly legitimate to you.

4. The client SDK's offline behaviour. Firestore caches locally and keeps working while disconnected, then reconciles. Writes that appear to succeed and then vanish are usually this, not a server-side failure — and the timing makes it look like an outage that ate your data.

Is it Firebase, or is it just me?

A decision procedure that resolves this quickly:

Check the status page and read which product and which region. Both qualifiers matter more here than at most providers.
Check Google Cloud too. Firebase runs on it, and a GCP incident can surface as a Firebase problem before Firebase has filed anything of its own.
Check the Firebase console for your project — quota, billing, rules. Project-level problems never appear on a status page.
Test from a clean client. Incognito, a different network, an unauthenticated read against a permissive path. This separates rules and auth problems from service problems in one step.
Check whether anything else is broken. If several unrelated providers are reporting problems at the same moment, the common cause is more likely upstream — a cloud region or a CDN — than each of them independently having a bad day.

That last step is most of why isuptime reads 102 status pages on one schedule rather than one at a time. Shared timing across unrelated providers is real evidence of a common cause. It is never proof of one.

What an incident log means for monitoring

Because Firebase publishes incidents rather than live component states, the page tells you about declared problems. Everything true of self-published status pages in general is true here, and one thing more: with no per-component dot, there is no continuous signal to disagree with. The document is silent until somebody writes in it.

Practically, that means your own telemetry is doing more work here than it would with a provider that publishes live component health. Client-side error rates on reads and writes, broken out by region, will tell you before the incident log does — and during a regional incident they will tell you whether it is your region, which is the only question that matters.

The preparation that follows is ordinary and worth doing anyway: know your project's region, keep a graph of client-side database errors, and make sure the failure path in your app is a stale cache and a message rather than a spinner that never resolves.

Live Firebase status on isuptime is read from Firebase's own public feed on a fixed schedule and shows what Firebase is currently reporting, with the timestamp of the check. It is not an independent test of whether Firebase works for you — here is exactly what it can and cannot tell you.