Firebase Realtime Database is the backbone of millions of mobile and web apps — it keeps data synchronized across clients in milliseconds and scales automatically on Google's infrastructure. But "managed" does not mean "always on from your application's point of view." Quota limits hit without warning, security rules that accidentally deny reads return cryptic permission-denied errors, and regional maintenance windows arrive with no automatic fallback. When Firebase goes down, your real-time sync stops cold.
Vigilmon gives you external visibility into Firebase Realtime Database availability so you know before your users do. This tutorial covers HTTP probe monitoring for Firebase REST endpoints and heartbeat monitoring for Firebase-dependent background workers.
Why Firebase Realtime Database Monitoring Matters
Google's internal health dashboards tell you whether Firebase is globally available. They cannot tell you:
- Whether your specific database instance is reachable from your application's network
- Whether your security rules have silently started blocking reads or writes
- Whether your app has hit its concurrent connection limit (free tier: 100, Spark: 100, Blaze: 200,000)
- Whether a quota exhaustion (data downloaded per day, storage) has disabled your database
- Whether your Firebase-dependent background sync jobs have stopped processing silently
These failures return healthy from Google's status page while users see blank screens or stale data. External monitoring through Vigilmon tests the actual path your application uses.
Step 1: Build a Firebase Health Endpoint
Firebase Realtime Database exposes a REST API you can probe directly. The simplest health check reads a known path and validates the response. Create a thin health endpoint in your backend that probes your Firebase instance and returns HTTP 200 or 503.
Node.js Example (Express)
// firebase-health.js
const express = require('express');
const admin = require('firebase-admin');
const app = express();
admin.initializeApp({
credential: admin.credential.applicationDefault(),
databaseURL: process.env.FIREBASE_DATABASE_URL,
});
const db = admin.database();
app.get('/health/firebase', async (req, res) => {
try {
const ref = db.ref('_healthcheck');
const ts = Date.now();
// Write a timestamp, then read it back
await ref.set({ ts });
const snap = await ref.once('value');
const val = snap.val();
if (!val || val.ts !== ts) {
return res.status(503).json({
status: 'degraded',
reason: 'read_write_mismatch',
});
}
return res.status(200).json({ status: 'ok', latency_ms: Date.now() - ts });
} catch (err) {
return res.status(503).json({ status: 'down', error: err.message });
}
});
app.listen(3001);
Python Example (FastAPI)
# firebase_health.py
import time, os
import firebase_admin
from firebase_admin import credentials, db
from fastapi import FastAPI
from fastapi.responses import JSONResponse
app = FastAPI()
cred = credentials.ApplicationDefault()
firebase_admin.initialize_app(cred, {
'databaseURL': os.environ['FIREBASE_DATABASE_URL']
})
@app.get('/health/firebase')
async def firebase_health():
try:
ref = db.reference('_healthcheck')
ts = int(time.time() * 1000)
ref.set({'ts': ts})
val = ref.get()
if not val or val.get('ts') != ts:
return JSONResponse(status_code=503, content={
'status': 'degraded',
'reason': 'read_write_mismatch',
})
return {'status': 'ok', 'latency_ms': int(time.time() * 1000) - ts}
except Exception as e:
return JSONResponse(status_code=503, content={
'status': 'down',
'error': str(e),
})
Deploy this endpoint alongside your app and verify it manually:
curl -i https://your-app.example.com/health/firebase
# HTTP/1.1 200 OK
# {"status":"ok","latency_ms":42}
Step 2: Configure a Vigilmon HTTP Monitor
- Log in to vigilmon.online and go to Monitors → New Monitor
- Choose HTTP / HTTPS
- Set the URL to your Firebase health endpoint:
https://your-app.example.com/health/firebase - Set the check interval to 1 minute
- Under Expected response, configure:
- Status code:
200 - Response body contains:
"status":"ok" - Response time threshold:
3000ms(Firebase writes are fast; a slow round-trip signals connection issues)
- Status code:
- Under Alert channels, assign your Slack or email channel
- Save the monitor
Vigilmon probes from multiple geographic regions. It requires multi-region consensus before opening an incident, so you won't be paged for transient single-probe blips. You get confident, actionable alerts when Firebase is genuinely unavailable from your users' perspective.
What This Catches
| Failure | Google Status Page | Vigilmon |
|---|---|---|
| Firebase regional outage | ✓ | ✓ |
| Security rule misconfiguration | ✗ | ✓ |
| Quota exhaustion | ✗ | ✓ |
| Network path failure from your app | ✗ | ✓ |
| Wrong databaseURL in config | ✗ | ✓ |
Step 3: Probe the Firebase REST API Directly
If you don't want to run a wrapper endpoint, Vigilmon can probe the Firebase REST API directly. Firebase exposes a JSON REST endpoint you can hit with a GET request using a database secret or a service account token.
Add a public _healthcheck node in your database rules for read access:
{
"rules": {
"_healthcheck": {
".read": true,
".write": false
}
}
}
Then set the node to a static value:
curl -X PUT \
"https://YOUR-PROJECT.firebaseio.com/_healthcheck.json?auth=YOUR_DATABASE_SECRET" \
-d '"ok"'
Now configure Vigilmon to probe:
- URL:
https://YOUR-PROJECT.firebaseio.com/_healthcheck.json - Expected body contains:
"ok" - Status code:
200
This approach requires no wrapper code, but it only validates read access — it won't catch write failures or permission denials on protected paths.
Step 4: Heartbeat Monitoring for Firebase-Dependent Workers
If you use Firebase Realtime Database as a job queue or trigger source for background workers, those workers will stop silently when Firebase becomes unreachable. The worker just stalls on on('value') and never processes another event.
Vigilmon heartbeat monitors detect silent worker death: your worker pings Vigilmon after each successful processing cycle. If the ping stops, Vigilmon fires an alert.
Set Up the Heartbeat Monitor
- In Vigilmon, go to Monitors → New Monitor → Heartbeat
- Name it:
firebase-sync-worker - Set the expected interval: 10 minutes (adjust to your event frequency)
- Set the grace period: 20 minutes
- Save — copy the unique heartbeat URL
Wire Into Your Worker
// Firebase listener with heartbeat
const axios = require('axios');
db.ref('jobs/pending').on('child_added', async (snap) => {
const job = snap.val();
try {
await processJob(job);
await snap.ref.remove();
// Ping Vigilmon heartbeat after successful processing
await axios.get(process.env.VIGILMON_HEARTBEAT_URL).catch(() => {});
} catch (err) {
console.error('Job failed:', err);
}
});
Step 5: Alerting Best Practices for Firebase
Firebase failures tend to be quota-related or configuration-related more often than infrastructure failures. Set up alert channels to reflect this:
- Firebase HTTP monitor → Slack + PagerDuty (P1 — real-time sync is down for all users)
- Worker heartbeat monitor → Slack + email (P2 — background processing stalled)
- Response time alert at 2000ms → Slack only (early warning for connection pressure before hard failure)
Set up a Vigilmon Status Page for Firebase alongside your other infrastructure monitors. When an incident opens, your team knows immediately rather than discovering it from user reports.
Summary
Firebase Realtime Database failures are sudden and user-visible — apps show stale data or fail to load entirely. Vigilmon gives you external visibility before users notice:
| Monitor Type | What It Covers |
|---|---|
| HTTP monitor on /health/firebase | Read/write availability, quota, rule errors |
| HTTP monitor on REST endpoint | Read availability, regional outage |
| Heartbeat monitor | Background worker liveness |
Get started free at vigilmon.online — your first Firebase monitor is running in under two minutes.