Firebase status

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.

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.