Is Firebase Down? Developer's Guide to Firebase Outages (2026)

Your app just stopped syncing. Authentication is failing with cryptic errors. Cloud Functions are timing out. Firestore reads are hanging. Cloud Messaging notifications aren't delivering. Your Firebase console might be loading slowly — or not at all. Firebase might be down, and since it's often your database, auth provider, hosting, and serverless backend all in one, a Firebase outage can take your entire app offline.

Here's how to confirm it's Firebase, respond immediately, and architect your app so the next outage doesn't break everything.

Is Firebase Actually Down Right Now?

Before you start clearing caches or redeploying, confirm it's a Firebase platform issue:

1. API Status Check — Firebase — Independent monitoring with response time history
2. Is Firebase Down? — Quick status check with 24h timeline
3. Firebase Official Status — Google's Firebase status dashboard
4. Downdetector — Firebase — Community-reported outages

What Firebase Outages Look Like

Firebase is a suite of interconnected services. Knowing which component is failing changes your response:

Component	Symptoms	Impact
Authentication	Login fails, token refresh errors, auth/network-request-failed	Users locked out
Firestore	Queries timeout, writes fail, UNAVAILABLE errors	Data layer broken
Realtime Database	Connection drops, .on() listeners die, NETWORK_ERROR	Live sync broken
Cloud Functions	503 errors, cold start timeouts, deployment failures	Backend logic down
Cloud Messaging (FCM)	Push notifications not delivering, messaging/server-unavailable	Notifications broken
Hosting	Site returns 502/503, slow global CDN responses	Website down
Cloud Storage	Upload/download fails, storage/retry-limit-exceeded	File operations broken
Remote Config	Config fetch fails, stale values served	Feature flags broken
Analytics	Events not logging (non-critical, usually delayed reporting)	Data collection paused

Key insight: Firebase runs on Google Cloud Platform. Outages often correlate with broader GCP issues in specific regions. US-central1 (Iowa) and europe-west1 (Belgium) are the most common Firebase regions — if those are down, impact is widespread.

Recent Firebase Incidents

• Jan 2026 — Firebase Authentication experienced elevated error rates for ~30 minutes, affecting sign-in and token refresh globally
• Nov 2025 — Firestore query latency spike in us-central1 region lasting 2 hours, reads delayed 3-10 seconds
• Sep 2025 — Cloud Functions deployment failures in multiple regions due to container registry issue
• Jul 2025 — Firebase Hosting CDN experienced intermittent 502 errors for EU users (~1 hour)
• Mar 2025 — Firebase Console and Admin SDK partially unavailable, client SDKs unaffected

Firebase is generally reliable (99.95%+ uptime), but when Google Cloud has issues, Firebase is impacted. Multi-region architectures are rare in Firebase — most projects are tied to a single region.

Architecture Patterns for Firebase Resilience

Local-First Data Architecture

Store critical data locally, sync to Firebase as a backup:

// Use IndexedDB as primary store, Firestore as sync layer
import { openDB, DBSchema, IDBPDatabase } from 'idb'

interface AppDB extends DBSchema {
  todos: {
    key: string
    value: {
      id: string
      text: string
      completed: boolean
      syncedAt: number | null
    }
  }
}

class LocalFirstStore {
  private db: IDBPDatabase<AppDB>
  private firestore: Firestore
  
  async init() {
    this.db = await openDB<AppDB>('myapp', 1, {
      upgrade(db) {
        db.createObjectStore('todos', { keyPath: 'id' })
      },
    })
    
    // Sync from Firestore on startup (if online)
    await this.syncFromFirestore()
    
    // Set up background sync
    this.startBackgroundSync()
  }
  
  // All reads from local DB (instant, works offline)
  async getTodos() {
    return await this.db.getAll('todos')
  }
  
  // Writes go to local DB first, then sync to Firestore
  async addTodo(text: string) {
    const todo = {
      id: crypto.randomUUID(),
      text,
      completed: false,
      syncedAt: null,
    }
    
    // Write locally first (instant)
    await this.db.put('todos', todo)
    
    // Sync to Firestore in background (non-blocking)
    this.syncToFirestore(todo).catch(console.error)
    
    return todo
  }
  
  private async syncToFirestore(todo: any) {
    try {
      await setDoc(doc(this.firestore, 'todos', todo.id), todo)
      
      // Mark as synced
      await this.db.put('todos', { ...todo, syncedAt: Date.now() })
    } catch (error) {
      console.error('Sync to Firestore failed, will retry later:', error)
    }
  }
  
  private startBackgroundSync() {
    // Periodically sync unsynced items
    setInterval(async () => {
      const todos = await this.db.getAll('todos')
      const unsynced = todos.filter(t => !t.syncedAt)
      
      for (const todo of unsynced) {
        await this.syncToFirestore(todo)
      }
    }, 30000) // Every 30 seconds
  }
  
  private async syncFromFirestore() {
    try {
      const snapshot = await getDocs(collection(this.firestore, 'todos'))
      const tx = this.db.transaction('todos', 'readwrite')
      
      for (const doc of snapshot.docs) {
        await tx.store.put({ ...doc.data() as any, syncedAt: Date.now() })
      }
      
      await tx.done
    } catch (error) {
      console.warn('Initial sync from Firestore failed:', error)
    }
  }
}

Fallback Authentication Strategy

When Firebase Auth is down, users shouldn't be locked out completely:

async function signInWithFallback(email: string, password: string) {
  try {
    // Try Firebase Auth first
    const userCredential = await signInWithEmailAndPassword(auth, email, password)
    
    // Cache successful credentials securely
    await storeAuthCache(email, userCredential.user.uid)
    
    return userCredential
  } catch (error: any) {
    // If network error, try cached session
    if (error.code === 'auth/network-request-failed') {
      console.warn('Firebase Auth unavailable, checking cached session')
      
      const cachedSession = await getAuthCache(email)
      if (cachedSession && await verifyPasswordLocally(email, password)) {
        // Return a "mock" user object from cache
        // WARNING: Only for read-only graceful degradation!
        return {
          user: {
            uid: cachedSession.uid,
            email: cachedSession.email,
            _fromCache: true, // Mark as cached
          }
        }
      }
    }
    
    throw error
  }
}

// Secure local password verification (for emergency fallback only)
async function verifyPasswordLocally(email: string, password: string) {
  // Store hashed password on successful login (not the raw password!)
  const stored = await secureStorage.get(`pwd_${email}`)
  if (!stored) return false
  
  const hash = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(password))
  const hashHex = Array.from(new Uint8Array(hash)).map(b => b.toString(16).padStart(2, '0')).join('')
  
  return hashHex === stored
}

Warning: Cached auth should only allow read-only operations. Never allow writes with cached credentials — it's a security risk and data can conflict.

Multi-Region Cloud Functions

For critical functions, deploy to multiple regions:

// functions/index.ts
import * as functions from 'firebase-functions'

// Deploy the same function to multiple regions
const regions = ['us-central1', 'europe-west1', 'asia-east1']

export const processPaymentUS = functions.region('us-central1').https.onCall(processPaymentHandler)
export const processPaymentEU = functions.region('europe-west1').https.onCall(processPaymentHandler)
export const processPaymentAsia = functions.region('asia-east1').https.onCall(processPaymentHandler)

function processPaymentHandler(data: any, context: functions.https.CallableContext) {
  // Your payment logic
  return { success: true }
}

Client-side region failover:

async function callFunctionWithRegionFailover(functionName: string, data: any) {
  const regions = ['us-central1', 'europe-west1', 'asia-east1']
  
  for (const region of regions) {
    try {
      const functions = getFunctions(undefined, region)
      const callable = httpsCallable(functions, functionName)
      return await callable(data)
    } catch (error) {
      console.warn(`${functionName} failed in ${region}, trying next region...`)
    }
  }
  
  throw new Error('All regions failed')
}

---

Monitoring Firebase Proactively

Health Check Dashboard

Build a real-time Firebase health monitor:

// app/dashboard/firebase-health/page.tsx
'use client'

export default function FirebaseHealthDashboard() {
  const [health, setHealth] = useState({
    auth: 'unknown',
    firestore: 'unknown',
    functions: 'unknown',
    lastCheck: null,
  })
  
  useEffect(() => {
    async function checkHealth() {
      const results = await checkFirebaseHealth() // From earlier
      setHealth({
        auth: results.auth ? 'healthy' : 'down',
        firestore: results.firestore ? 'healthy' : 'down',
        functions: results.functions ? 'healthy' : 'down',
        lastCheck: new Date(),
      })
    }
    
    checkHealth()
    const interval = setInterval(checkHealth, 60000) // Every minute
    return () => clearInterval(interval)
  }, [])
  
  return (
    <div className="health-dashboard">
      <h1>Firebase Health Status</h1>
      <ServiceStatus name="Authentication" status={health.auth} />
      <ServiceStatus name="Firestore" status={health.firestore} />
      <ServiceStatus name="Cloud Functions" status={health.functions} />
      <p>Last checked: {health.lastCheck?.toLocaleString()}</p>
    </div>
  )
}

Error Rate Tracking

Monitor Firebase error patterns in your app:

// Track Firebase errors globally
function initFirebaseErrorTracking() {
  const originalConsoleError = console.error
  
  console.error = (...args) => {
    // Check if it's a Firebase error
    const errorString = args.join(' ')
    if (errorString.includes('firebase') || 
        errorString.includes('firestore') ||
        errorString.includes('auth/')) {
      
      // Log to your analytics
      logFirebaseError({
        message: errorString,
        timestamp: Date.now(),
        service: detectFirebaseService(errorString),
      })
    }
    
    originalConsoleError.apply(console, args)
  }
}

function detectFirebaseService(errorString: string): string {
  if (errorString.includes('auth/')) return 'authentication'
  if (errorString.includes('firestore')) return 'firestore'
  if (errorString.includes('functions/')) return 'functions'
  if (errorString.includes('storage/')) return 'storage'
  return 'unknown'
}

// Alert ops when error rate spikes
async function checkFirebaseErrorRate() {
  const recentErrors = await db.select().from(errorLogs)
    .where(sql`timestamp > ${Date.now() - 5 * 60 * 1000}`) // Last 5min
    .groupBy('service')
  
  for (const service of recentErrors) {
    if (service.count > 50) {
      await alertOps(`High Firebase ${service.service} error rate: ${service.count} errors in 5min`)
    }
  }
}

---

Common Firebase Error Codes

Error	Meaning	Fix
auth/network-request-failed	Firebase Auth unavailable	Implement cached auth fallback
auth/too-many-requests	Rate limited	Implement exponential backoff
unavailable (Firestore)	Firestore temporarily unavailable	Enable offline persistence, retry
deadline-exceeded	Query/write timeout	Optimize query, add indexes, retry
permission-denied	Security rules rejected	Check Firestore rules
functions/internal	Cloud Function crashed	Check function logs, add error handling
functions/deadline-exceeded	Function timed out (60s default)	Optimize function or increase timeout
storage/retry-limit-exceeded	Upload failed after retries	Check network, file size limits
messaging/server-unavailable	FCM temporarily down	Queue notifications, retry later
not-found	Resource doesn't exist	Check collection/document paths

Pro tip: Firebase error codes follow a pattern: service/error-code. The service prefix tells you which Firebase product is affected.

---

Firebase vs. Self-Hosted Alternatives: The Tradeoff

When Firebase has issues, some teams consider alternatives. Here's the real comparison:

Firebase:

• ✅ Fully managed — zero DevOps overhead
• ✅ Integrated auth, database, hosting, functions in one platform
• ✅ Generous free tier, scales automatically
• ✅ Built-in offline support in SDKs
• ❌ Vendor lock-in (migrations are painful)
• ❌ Limited control over infrastructure
• ❌ Rare but impactful outages

Supabase (open-source Firebase alternative):

• ✅ Built on Postgres (more familiar for backend devs)
• ✅ Can self-host if needed
• ✅ GraphQL and REST API
• ❌ Smaller ecosystem
• ❌ Less mature offline support

AWS Amplify:

• ✅ Uses proven AWS services (Cognito, AppSync, S3)
• ✅ Multi-region by design
• ❌ More complex setup
• ❌ Higher learning curve
• ❌ More expensive at scale

Appwrite (self-hosted):

• ✅ Full control, can run anywhere
• ✅ Docker-based, easy to deploy
• ❌ You're responsible for uptime
• ❌ Smaller community

The pragmatic approach: Firebase's offline-first architecture handles most outages gracefully. Enable persistence, implement retry logic, and monitor proactively. The time you'd spend managing self-hosted infrastructure is better spent building features. Consider alternatives only if Firebase outages genuinely hurt your business more than managing infrastructure would.

---

Frequently Asked Questions

Q: How long do Firebase outages typically last?
A: Most Firebase incidents resolve within 30-90 minutes. Major outages (affecting multiple services) are rare and typically under 2 hours.

Q: Does Firebase have a 99.9% uptime SLA?
A: Firebase offers SLAs on Blaze (pay-as-you-go) plan for Firestore (99.999% multi-region, 99.9% single-region) and some other services. Check Firebase SLAs for specifics.

Q: Will my queued writes be lost if Firebase is down?
A: No. With offline persistence enabled, writes are queued locally and automatically sync when connectivity is restored. Writes persist across app restarts.

Q: Can I deploy my Firestore database to multiple regions?
A: No. Firestore databases are single-region (with automatic replication within that region). However, you can use multiple Firebase projects in different regions and route traffic accordingly.

Q: Should I switch from Firebase to Supabase?
A: Only if vendor lock-in concerns or Postgres features outweigh Firebase's integrated ecosystem and offline support. Most teams are better off building resilience into their Firebase architecture.

---

Get Notified Before Your Users Do

Stop discovering Firebase outages through user complaints:

1. Bookmark apistatuscheck.com/api/firebase for real-time status
2. Set up Discord/Slack alerts via API Status Check integrations
3. Subscribe to status.firebase.google.com for official updates
4. Add the health check endpoint above to your monitoring stack
5. Enable Firebase Performance Monitoring to detect issues before status pages report them

Firebase outages are rare but high-impact. The best teams don't just monitor Firebase — they build apps that keep working even when Firebase doesn't.

---

API Status Check monitors Firebase and 100+ other APIs in real-time. Set up free alerts at apistatuscheck.com.