# Firebase status

> Is Firebase down? Live status, uptime history, and per-region response times measured by our own probes every 2 minutes from five locations.

Published: 2026-08-26 | Canonical: https://yoping.me/status/firebase

## How we check Firebase

We watch firebase.googleapis.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the API host the Firebase SDKs and tooling talk to, and we pin the exact response an unauthenticated request receives rather than expecting a 2xx from a Google API root. A project's own database and storage buckets answer only to authorised requests, so they cannot be probed honestly from outside.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/firebase. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## What is Firebase?

Firebase is Google's application platform, and the most important thing
to understand about it is that the name covers a collection of separate
products rather than one service. Authentication, Firestore, the older
Realtime Database, Cloud Functions, Hosting, Cloud Storage, and Cloud
Messaging share a console and a set of SDKs, and very little else. They
are built on different infrastructure, they have separate incident
histories, and they fail independently.

That structure is why "is Firebase down" is a harder question than it
sounds. An application can have working authentication and a Firestore
that is refusing writes, or functions timing out while everything else is
fine. Any single indicator, including the one at the top of this page,
compresses a set of independent services into one dot, which is useful
as a first signal and misleading if treated as the whole answer. Google's
own dashboard breaks it down by product, and during an incident that
breakdown is what you actually need.

Security rules are the most common source of failures that look like
outages and are not. Firestore and Storage evaluate every request against
rules you deploy, and a rule that does not match a query rejects it with
permission denied. Deploy a rules change and an unrelated screen stops
loading; sign a user out somewhere and a client silently becomes
anonymous and loses access to everything scoped to their account. Both
present as data disappearing, which is alarming and entirely local to
your configuration.

Cost is the other thing that behaves unlike a traditional backend.
Firestore bills per document read, which means the expensive operation is
often a listener rather than a user. A component that subscribes to a
large collection, a query without a limit, or a subscription re-created
on every render can multiply reads by orders of magnitude without
changing anything a user would notice. Teams discover this on an invoice
rather than in monitoring, and the fix is nearly always narrowing a query
rather than adding infrastructure.

Cold starts round out the list of things that feel like problems and are
not. A Cloud Function that has been idle takes longer on its first
invocation while an instance starts, so a low-traffic application shows
occasional slow requests with no failures behind them. It is a
predictable property of the runtime, it never appears on a status page,
and for latency-sensitive paths it is addressed by keeping a minimum
number of instances warm rather than by waiting for it to stop.

## Frequently asked questions

### Is Firebase down right now?

Check the board above; it reflects our own probes against Firebase's API host from all five of our regions, refreshed every couple of minutes. Firebase is a family of services that fail independently, so treat this as a platform-level signal rather than a verdict on every product.

### Which Firebase product is actually broken?

Check Google's own status dashboard, which breaks the platform down by product, because Firebase is not one service. Authentication, Firestore, Realtime Database, Cloud Functions, Hosting, Storage, and Cloud Messaging run separately and it is routine for one to be degraded while the others are untouched. A single overall verdict, ours included, cannot tell you which.

### My reads are failing with permission denied. Is Firebase down?

No, permission denied means Firebase answered you and your security rules rejected the request. This appears constantly after a rules deployment, when a query no longer matches what the rules allow, or when a client is signed out and running as an anonymous user without realising it. The rules playground in the console reproduces the exact request, which resolves it faster than any outage investigation.

### Why did my Firebase bill jump without a traffic increase?

Usually because of read volume rather than users. Firestore charges per document read, and a listener attached to a large collection, a query without a limit, or a component re-subscribing on every render can multiply reads enormously with no visible change in the application. The usage tab breaks this down, and it is worth checking before assuming a pricing change.

### Do Cloud Functions cold starts count as downtime?

No, though they can feel like it. A function that has not run recently takes noticeably longer on its first invocation while its instance starts, which produces occasional slow requests in an otherwise healthy application. Minimum instances exist to avoid this for latency-sensitive paths, and it will not appear on any status page because nothing has failed.