# Firepulse: Full Documentation > Firebase app monitoring at a glance. Realtime alerts and signals (crashes, performance, Cloud Functions logs) for indie devs and small teams using Google Cloud / Firebase. Android app by Mobile Squad. **Canonical URL:** https://mobile-squad.com/apps/firepulse/ **Compact index:** https://mobile-squad.com/apps/firepulse/llms.txt **Last updated:** 2026-05-23 --- ## Core concept The Firebase console is full-featured but heavy on a phone. Firepulse strips it to the operational essentials, what's broken, what's slow, what's pinging, so an oncall dev can answer "is my app on fire?" from a pocket-screen in 5 seconds. ### Signals surfaced - **Crashlytics:** new issues, regression detection, version-pinned crash-free rate. - **Performance:** P50/P95/P99 traces for key flows. - **Cloud Functions:** last N invocations, error rate, log tail. - **Authentication:** active users last hour / day. - **Realtime DB / Firestore:** read/write QPS, error spikes. ### Alerts Configurable push notifications for: new crash signature, crash-free rate drop >X%, P95 trace regression >Y%, Cloud Function error rate >Z%, auth provider outage. --- ## Use cases - Indie dev shipping side-projects: replaces refreshing the web console. - Small team oncall rotation: phone-first alerting. - Travel / cafe debugging: full session from a phone screen. --- ## Auth & security - OAuth via Google account that has Firebase project access. - Read-only by default; write-mutating actions opt-in per project. - No data leaves your device beyond standard Google API calls. --- ## Page 1: Firestore Cost & Usage Estimator URL: https://mobile-squad.com/apps/firepulse/firestore-cost-estimator/ ### TL;DR Interactive calculator that projects a monthly Firestore bill from document reads, writes, deletes, storage GB, and outbound bandwidth GB. Applies free-tier deductions and 2026 Firestore pricing to show cost per line item. ### What the tool does - **Input:** Monthly reads, writes, deletes (count), storage (GB), egress (GB), region type (single vs multi) - **Output:** Cost breakdown per meter + bar chart + annual projection + optimisation tip - **Persistence:** localStorage key `fp-firestorecostestimator-v1`, no account required - **Formula:** (billable_ops / 100,000) × rate_per_100K; billable = max(0, actual − free_tier) ### Firestore pricing (2026) | Meter | Free tier | Rate | |-------|-----------|------| | Reads | 50K/day (~1.5M/month) | $0.06/100K | | Writes | 20K/day (~600K/month) | $0.18/100K | | Deletes | 20K/day (~600K/month) | $0.02/100K | | Storage | 1 GB | $0.18/GB | | Egress | 10 GB/month | $0.12/GB | Multi-region (nam5, eur3) applies ×1.2 multiplier to writes only. ## Page 2: RTDB vs Firestore Latency Comparison URL: https://mobile-squad.com/apps/firepulse/rtdb-vs-firestore-latency/ ### TL;DR Interactive benchmark visualiser comparing Firebase Realtime Database and Cloud Firestore latency for reads, writes, listeners, and queries, with cold/warm connection states and same/cross-region configurations. ### What the tool does - **Input:** Operation type (read/write/listener/query/offline), connection state (warm/cold), client-to-server region - **Output:** Side-by-side latency bars + bar chart + winner verdict - **Persistence:** localStorage key `fp-rtdbvsfirestorelatency-v1`, no account required - **Data source:** Indicative median values from community benchmarks and Firebase documentation ### Latency reference (warm, same region) | Operation | RTDB | Firestore | |-----------|------|-----------| | Simple read | ~50ms | ~100ms | | Write | ~90ms | ~180ms | | Listener first sync | ~70ms | ~140ms | | Structured query | N/A | ~160ms | | Cached/offline | ~5ms | ~10ms | RTDB uses persistent WebSocket; Firestore uses gRPC over HTTP/2. Cold starts add 150–350ms. Cross-continent adds 100–250ms. ## Page 3: Firebase Security Rule Leak Tester URL: https://mobile-squad.com/apps/firepulse/firebase-security-rule-tester/ ### TL;DR A 10-question audit checklist that scores Firebase security rule configurations against known vulnerability patterns. Users check which patterns exist in their rules; the tool assigns an A–F grade with prioritised fix recommendations per finding. ### What the tool does - **Input:** 10 yes/no checkbox questions about Firestore/RTDB security rule patterns - **Output:** A–F security grade, per-finding risk classification, fix code snippets - **Persistence:** localStorage key `fp-firebasesecurityruletester-v1`, no account required - **Note:** Does not connect to Firebase: educational audit only ### 10 audited patterns | Pattern | Risk | |---------|------| | `allow read, write: if true` | Critical | | No auth check on reads | Critical | | No ownership check | High | | Unsecured subcollections | High | | Write field not restricted | High | | Admin collection unlocked | Medium | | `get()` without null guard | Medium | | No write rate limiting | Medium | | Custom claims without expiry | Low | | Rules never reviewed | Low | ## Page 4: Cloud Functions Execution Cost Calculator URL: https://mobile-squad.com/apps/firepulse/cloud-functions-cost-calculator/ ### TL;DR Calculates monthly Firebase Cloud Functions cost from invocations, memory allocation, execution duration, and outbound networking. Applies 1st gen pricing with free-tier deductions across all four billing meters. ### What the tool does - **Input:** Monthly invocations, memory (128MB–8GB), average duration (ms), egress (GB) - **Output:** Cost breakdown per meter + bar chart + cost-per-million + annual projection - **Persistence:** localStorage key `fp-cloudfunctionscostcalculator-v1`, no account required - **Formula:** GB-s = invocations × (memory_GB) × ceil(duration_ms/100)×0.1; cost = max(0, GB-s − 400000) × $0.0000025 ### Cloud Functions 1st gen pricing (2026) | Meter | Free tier | Rate | |-------|-----------|------| | Invocations | 2M/month | $0.40/M | | Compute | 400K GB-s | $0.0000025/GB-s | | CPU | 200K GHz-s | $0.0000100/GHz-s | | Egress | 5 GB | $0.12/GB | ## Page 5: Push Notification Delivery Rate Estimator URL: https://mobile-squad.com/apps/firepulse/push-notification-delivery-estimator/ ### TL;DR Estimates FCM push notification delivery rate and open rate based on subscriber count, platform (Android/iOS/mixed), payload size, user engagement tier, and send timing. Shows a delivery funnel: targeted → delivered → opened. ### What the tool does - **Input:** Subscriber count, platform, payload size, engagement tier, send timing, optional open rate override - **Output:** Estimated delivered count, opened count, delivery funnel, bar chart, optimisation tip - **Persistence:** localStorage key `fp-pushnotificationdeliveryestimator-v1`, no account required - **Data source:** Industry benchmarks from Firebase, OneSignal, and Airship reports ### FCM delivery rate benchmarks | Scenario | Delivery rate | Open rate | |----------|---------------|-----------| | Android high-engagement | 90–97% | 5–12% | | Android mixed | 70–85% | 3–8% | | Android dormant | 40–65% | 1–3% | | iOS high-engagement | 88–95% | 4–10% | | iOS vs installs (~50% opt-in) | 34–41% | 1–3% | ## Page 6: Serverless App Scalability: 2026 Benchmarks URL: https://mobile-squad.com/apps/firepulse/serverless-app-scalability-2026/ ### TL;DR Firebase Cloud Functions benchmark data for 2026: Node.js 22 cold starts ~320ms median, warm ~30ms. Minimum instances eliminates cold starts at $2–5/month per function. Serverless is the right default architecture for new mobile backends. ### Key benchmarks | Runtime | Cold start median | p95 | Warm | |---------|-------------------|-----|------| | Node.js 20 | ~380ms | ~1,100ms | ~35ms | | Node.js 22 | ~320ms | ~950ms | ~30ms | | Go 1.22 | ~220ms | ~600ms | ~20ms | ## Page 7: Firebase Ecosystem Statistics & Adoption Trends 2026 URL: https://mobile-squad.com/apps/firepulse/firebase-ecosystem-statistics-2026/ ### TL;DR Firebase has an estimated 5–7M active projects in 2026. Firebase Authentication (71%) and Cloud Firestore (65%) are the most used products. RTDB is declining (-8% YoY), replaced by Firestore for new projects. Supabase is the fastest-growing competitor at ~14% developer share. ## Page 8: Mobile Backend Security Trends 2026 URL: https://mobile-squad.com/apps/firepulse/mobile-backend-security-trends-2026/ ### TL;DR 68% of mobile backend breaches are caused by misconfigured access controls, not exploits. Automated Firebase misconfiguration scanning has industrialised in 2026. Firebase App Check adoption grew to ~28% of production projects. Read-only architectural patterns reduce blast radius of credential compromise. ## Page 9: Read-Only Consoles & DevOps Security 2026 URL: https://mobile-squad.com/apps/firepulse/read-only-consoles-devops-security-2026/ ### TL;DR Purpose-built read-only monitoring tools are becoming standard for production observability. Full-access monitoring credentials create unnecessary attack surface; a read-only credential's blast radius is limited to data exposure vs data destruction. 41% of enterprises now have formal least-privilege monitoring policies (up from 24% in 2023). ## Page 10: Top 10 Firebase Misconfigurations 2026 URL: https://mobile-squad.com/apps/firepulse/firebase-misconfigurations-2026/ ### TL;DR The 10 most impactful Firebase configuration mistakes: public Firestore collections, no billing alerts, unsecured subcollections, Cloud Functions without maxInstances, no App Check, unoptimized indexes, stale FCM tokens, email enumeration enabled, no write frequency limits, and no error alerting. Each listed with a specific fix. ## Citation - **App name:** Firepulse - **Publisher:** Mobile Squad: https://mobile-squad.com/ - **Founder:** Erwan Alliaume - **Canonical URL:** https://mobile-squad.com/apps/firepulse/ Last updated 2026-08-12. --- # Full page text Everything below is the complete readable text of the 11 pages under /apps/firepulse/, generated from the pages themselves so this file matches what it promises: the whole app in one fetch. Each section carries its own last-modified date. --- ## Firepulse **URL:** https://mobile-squad.com/apps/firepulse/ **Last modified:** 2026-08-12 App 05 · Developer tools · Android (iOS soon) ### Firepulse Firepulse is your Firebase projects in your pocket. Read-only. Firepulse is a read-only mobile console for Firebase projects . Sign in with Google, browse every project on your account, and check the metrics that matter, Firestore reads/writes, Crashlytics , Analytics, hosting traffic, without opening a laptop. Firepulse is not affiliated with Google. Get it on Google Play for Firepulse Website Read-only OAuth scopes iOS coming soon - Read-only OAuth scopes, cannot modify your projects - Global dashboard across every project on your account - Side-by-side project compare - Server-side daily / weekly push digests (no battery drain) - Home-screen widgets for key metrics - Crashlytics and Analytics deep-dive per project - OAuth refresh tokens encrypted with Google Cloud KMS - Demo project for evaluation without granting scopes Short answer. Firepulse is a read-only mobile console for Firebase. Sign in with Google and you can browse every project on the account, check Firestore reads and writes, Crashlytics, Analytics and hosting traffic, and compare projects side by side. It cannot write, delete or change configuration, which is the point: an on-call check should not be able to break production. #### What can you do with Firepulse? ##### Global Dashboard One tile per project, fit-to-screen grid, fullscreen wall-display mode. Pick any metric, active users, crash-free rate, function invocations , Firestore reads, hosting bandwidth, p95 latency, and see it across every project at a glance. ##### Project Directory Every Firebase project on your Google account. Sortable by name, status, or starred. Search, refresh, open. ##### Per-project deep dive Overview, Analytics, Backend, Services, Deploys, and Explore tabs. Real numbers, real charts, no fluff. ##### Side-by-side Compare Pick two projects, view Analytics, Crashlytics, and Functions side by side over 24h / 7d / 30d / 90d. ##### Server-side push digests Daily or weekly, at 9 AM, 12 PM, or 7 PM local. Up to 2 headline metrics, any number of projects. Assembled server-side (Cloud Scheduler → dispatcher → push) and delivered as a single notification with per-project breakdowns and delta arrows. No background polling. ##### Home-screen widgets Native Android widgets render your favourite metrics directly on the home screen. iOS widgets coming soon. #### Free vs Pro Pro is a monthly subscription. Cancel anytime. | Feature | Free | Pro | | Project directory & search | ✓ | ✓ | | Per-project analytics view | ✓ | ✓ | | Crashlytics & error rates | ✓ | ✓ | | Global multi-project dashboard | — | ✓ | | Side-by-side project compare | — | ✓ | | Server-side push digests | — | ✓ | | Android home-screen widgets | — | ✓ | | Extended metric history (90d) | — | ✓ | #### Why is Firepulse read-only by design? Firepulse cannot create, modify, or delete anything in your Firebase projects. Beyond basic profile and email , every Google OAuth scope it requests is read-only: - firebase.readonly - analytics.readonly - monitoring.read - logging.read - cloud-platform.read-only If you turn on notifications, a Google refresh token is stored on our backend so the digest can be assembled server-side while you sleep. The token is encrypted at rest with Google Cloud KMS envelope encryption and used only to read the metrics and projects you selected. Delete the notification and the token is revoked and erased, or revoke at any time from myaccount.google.com. #### Built for ##### Solo developers Glance at production from the bus. ##### Small teams One app per role, not five web tabs. ##### On-call engineers Crash and error trends now, not after boot. ##### Founders DAU and crash-free rate without opening Looker. #### What does Firepulse look like? #### A real morning with Firepulse Leila ships two Firebase apps, a B2C product with 8,000 daily users and an internal tool for her team. She checks both every morning without opening a laptop. 7:10 AM · Push notification arrives Firepulse delivers her daily digest at 7 AM. The notification reads: B2C app, 7,840 active users (↑ 4%), crash-free rate 99.1% (↓ 0.3%). The delta arrow on crash-free is slightly down. She taps the notification. 7:11 AM · Per-project deep dive Firepulse opens directly to the B2C project. She checks the Crashlytics tab, three new crash signatures, all on Android 14, one on a specific OEM. She screenshots the trend chart and pastes it into Slack before she's finished her coffee. Total time: 90 seconds, no laptop needed. 7:13 AM · Side-by-side compare She pulls up Compare, sets B2C vs the internal tool, picks "7 days." Function invocations are flat on the internal tool, good, nothing unusual. She closes the app. Her first standup is at 9 AM. She already knows the agenda. No laptop. No browser tabs. None of this required opening a browser, signing in to the Firebase console, or loading five different web pages. The digest was assembled server-side overnight, Leila's phone didn't poll anything while she slept. Her battery looks the same as when she charged it. #### What Firepulse doesn't do Firepulse is read-only by design. That constraint is intentional and worth understanding before you install. ##### No writes, ever You cannot create, update, or delete anything in your Firebase projects from Firepulse. No Firestore writes, no rule changes, no user management. If you need to make a change, open the Firebase console on your laptop, that's the right tool for writes. ##### Not a full Firebase console replacement Firepulse shows the metrics that matter for monitoring. It doesn't expose every Firebase product or every configuration panel. For setup, migrations, or schema changes, use the Firebase web console directly. ##### Not affiliated with Google or Firebase Firepulse is an independent app built by Mobile Squad. It uses public Firebase APIs with read-only OAuth scopes. Firebase is a trademark of Google LLC. Firepulse is not endorsed by, sponsored by, or affiliated with Google in any way. ##### No Firestore document browser Firepulse shows aggregate metrics, reads, writes, bandwidth, error rates. It doesn't let you browse individual Firestore documents or collections. For direct data inspection, use the Firebase console or a dedicated admin tool. #### FAQ Is Firepulse really read-only? Yes. Every OAuth scope is read-only. The app cannot create, modify, or delete anything in your Firebase projects. How do daily digests work? Daily or weekly. 9 AM, 12 PM, or 7 PM local. Up to 2 metrics, any number of projects. Cloud Scheduler → dispatcher → push. Single notification with per-project breakdowns and delta arrows. No background polling, no battery drain. Where are my OAuth tokens stored? Only when notifications are enabled. Refresh tokens are stored on the backend encrypted at rest with Google Cloud KMS envelope encryption. Delete the notification or revoke at myaccount.google.com to wipe. iOS support? Coming soon. Android-first today. Is this affiliated with Google or Firebase? No. Firepulse is not affiliated with, endorsed by, or sponsored by Google or Firebase. Firebase is a trademark of Google LLC. #### Tools & Guides Tool ##### Firestore Cost & Usage Estimator Project your monthly Firebase bill from expected reads, writes, deletes, storage, and bandwidth. Tool ##### RTDB vs Firestore Latency Comparison Interactive benchmark visualiser comparing latency for reads, writes, listeners, and queries, cold and warm connections. Tool ##### Firebase Security Rule Leak Tester Audit 10 common Firestore and RTDB security rule misconfigurations. Get a risk grade and prioritised fix list. Tool ##### Cloud Functions Execution Cost Calculator Factor in invocations, memory, duration, and outbound networking to project your monthly Functions bill. Tool ##### Push Notification Delivery Rate Estimator Estimate FCM delivery rates based on platform, payload size, and user engagement tier. Plan your notification strategy. Post ##### Serverless App Scalability: 2026 Benchmarks Cloud Functions cold start data, cost-per-scale analysis, and minimum instances for production apps. Post ##### Firebase Ecosystem Statistics 2026 Developer counts, product usage breakdown, RTDB vs Firestore trends, and the competitive landscape. Post ##### Mobile Backend Security Trends 2026 Firebase data leaks, App Check adoption, token security, and practical fixes for indie developers. Post ##### Read-Only Consoles & DevOps Security 2026 Why least-privilege monitoring is becoming standard and how it reduces production incident blast radius. Post ##### Top 10 Firebase Misconfigurations 2026 Public collections, billing abuse, unprotected functions, and the specific fix for each common mistake. #### Glance at production. From anywhere. Try the pinned Demo project before connecting anything real. Get it on Google Play for Firepulse Website Back to Mobile Squad #### Guides, tools & resources Tools & calculators - Firestore cost & usage estimator - RTDB vs Firestore latency comparison - Firebase security rule leak tester - Cloud Functions execution cost calculator - Push notification delivery rate estimator - Firebase monitoring glossary, 34 terms Research & data - Serverless app scalability: 2026 benchmarks - Firebase ecosystem statistics & adoption 2026 - Mobile backend security trends 2026 - Read-only consoles & DevOps security 2026 - Top 10 Firebase misconfigurations 2026 Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . Last updated 12 August 2026 --- ## Firestore Cost & Usage Estimator **URL:** https://mobile-squad.com/apps/firepulse/firestore-cost-estimator/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Firepulse · Developer tools · Free estimator ### Firestore Cost & Usage Estimator Project your monthly Firebase bill before it arrives. Enter your expected monthly Firestore reads, writes, deletes, stored data, and outbound bandwidth. The estimator applies the current Firestore pricing tiers, subtracts the free allowance, and shows you the cost breakdown by line item, so you can optimise before you scale. Short answer. This free estimator projects a monthly Firestore bill from your expected reads, writes, deletes, stored data and outbound bandwidth. It applies the current pricing tiers, subtracts the free allowance, and breaks the total down by line item so you can see which operation is actually driving the cost. Want live Firebase metrics on your phone? Firepulse reads Firestore, Crashlytics, and Analytics, read-only, no laptop needed. Get on Google Play #### Monthly usage inputs Document reads / month Free tier: 1,500,000/month (50K/day) Document writes / month Free tier: 600,000/month (20K/day) Document deletes / month Free tier: 600,000/month (20K/day) Stored data (GB) Free tier: 1 GB included Outbound bandwidth (GB/month) Free tier: 10 GB/month Deployment region Single region (default) Multi-region (nam5 / eur3), write ×1.2 Calculate cost Load example (50K DAU app) Reset Estimated monthly cost Annual projection Monitor Firestore usage in real time, on your phone, read-only Firepulse shows live reads/writes, Crashlytics, and Analytics across all your Firebase projects, no laptop, no browser tabs. Get it on Google Play #### How does Firestore billing work? Firestore charges on four independent meters. Understanding each one is the difference between a $5 bill and a $500 surprise at end of month. Document reads ##### $0.06 per 100,000 reads Every document returned by a get, query, or real-time listener snapshot counts as one read. A query returning 200 documents costs 200 reads regardless of how many fields you actually access. The free tier gives 50,000 reads per day (~1.5M/month). Document writes ##### $0.18 per 100,000 writes Each set, add, or update counts as one write, even if you only change a single boolean field. Transactions count each write separately. Multi-region deployments (nam5, eur3) multiply writes by ~1.2× due to replication overhead. Free tier: 20,000 writes/day. Storage ##### $0.18 per GB stored Storage includes document data, indexes, and metadata. Indexes are often larger than the raw document data, every array field and map creates additional index entries. The free tier includes 1 GB of total storage. Deleting documents reduces storage costs but not immediately. Outbound bandwidth ##### $0.12 per GB egress Data transferred from Firestore to your clients counts as egress . Reads from the same Google Cloud region as your Firestore instance are free. Cross-region reads within GCP are reduced rate. Reads from outside GCP (mobile apps, browsers) incur the full $0.12/GB rate. Free tier: 10 GB/month. #### Firestore pricing reference (2026) | Meter | Free tier | Paid rate | | Document reads | 50,000 / day | $0.06 / 100K | | Document writes | 20,000 / day | $0.18 / 100K | | Document deletes | 20,000 / day | $0.02 / 100K | | Storage | 1 GB | $0.18 / GB | | Outbound bandwidth | 10 GB / month | $0.12 / GB | Source: Firebase pricing page. Free tier amounts are daily limits for reads/writes/deletes and a monthly limit for storage and bandwidth. Multi-region instances (nam5, eur3) apply a ~1.2× multiplier to write operations only. #### How to reduce your Firestore bill Strategy 1, Cache aggressively ##### Use Firestore offline persistence Firestore's built-in offline cache serves documents from local storage without hitting the network. For read-heavy apps, this alone can reduce billed reads by 30–70%. Enable it with enableIndexedDbPersistence() on web or the default SDK cache on iOS/Android. Strategy 2, Denormalise data ##### Reduce documents per screen Each document read in a query costs one read. A screen loading a list of 20 items reads 20 documents. Denormalising frequently co-read data into fewer documents can cut reads dramatically. Store derived counts and summaries directly in parent documents rather than aggregating from subcollections. Strategy 3, Limit query results ##### Always use .limit() on queries An unbounded query on a collection that grows over time will progressively increase read counts. Paginate with .limit(25) and cursor-based pagination. A feed of 100 posts returning 100 documents per load at 10,000 daily active users = 1 million reads per day, just for one screen. Strategy 4, Debounce writes ##### Batch updates instead of per-keystroke writes Real-time sync features (collaborative editing, live presence) can generate enormous write counts. Use debounce timers (500ms–2s) to batch rapid state changes into single writes. Firestore's WriteBatch API lets you bundle up to 500 writes into a single atomic operation counted as 500 writes, but it eliminates round-trip overhead. Strategy 5, Prune indexes ##### Disable single-field index exemptions Firestore automatically creates indexes on every field in every document. For large text fields, array fields, and map fields with high cardinality, these auto-indexes consume significant storage and add write overhead. Use the Firestore console to add single-field index exemptions for fields you never query. Strategy 6, Monitor in Firepulse ##### Watch usage trends on your phone Firestore cost surprises usually follow a usage spike, a blog post goes viral, a feature ships with a missing .limit() call, or a new release triggers a read storm. The Firepulse app tracks Firestore reads and writes across all your projects. Get a daily digest notification before the month-end bill arrives. #### How to use this estimator Step 1: Find your usage numbers ##### Pull metrics from Firebase console Open the Firebase console → Usage and billing tab. The "Firestore" section shows reads, writes, deletes, storage, and network egress for the current billing month. Use 30-day averages rather than peak-day values for realistic estimates. Step 2: Estimate growth ##### Project reads per DAU Reads are usually the largest line item. Estimate reads per daily active user per session (typical range: 20–200 reads per user). Multiply by your DAU and 30 days. For a new project, use the "Load example" button to start with a realistic 50K DAU scenario. Step 3: Input and calculate ##### Enter values and review the breakdown Fill in each field and click "Calculate cost." The results show each line item, how much is covered by the free tier, and the billable cost. The bar chart lets you see which meter dominates your bill, usually reads for consumer apps, writes for collaboration tools. Step 4: Monitor on your phone ##### Track actuals with Firepulse Once live, the Firepulse app shows Firestore reads and writes across your Firebase projects. Set up a daily digest notification to get a morning summary of usage across all projects, without logging into the Firebase console. Free on Google Play. #### Common Firestore cost scenarios Real Firestore bills vary enormously by app type. These illustrative scenarios help calibrate your estimates against typical apps at each scale tier. Scenario A · Hobby project ##### Under free tier 100 DAU · 50 reads/user/day · 5 writes = 150K reads, 15K writes/day. Both under free limits. Monthly bill: $0.00 . Scenario B · Growing app ##### ~5K DAU 5K DAU · 100 reads · 10 writes/user/day = 15M reads, 1.5M writes/month. ~5 GB stored, 20 GB egress. Monthly bill: ~$30–40 . Scenario C · Scale ##### ~50K DAU 50K DAU · 80 reads · 8 writes/user/day = 120M reads, 12M writes/month. 50 GB stored, 150 GB egress. Monthly bill: ~$200–280 . #### FAQ How does Firestore charge for reads? Firestore charges $0.06 per 100,000 document reads after the free tier of 50,000 reads per day (about 1.5 million per month). A "read" is one document fetched from the database, whether by direct get, query result row, or real-time listener snapshot. Each document returned in a query counts as one read even if you only examine one field. What is included in Firestore's free tier? The Spark (free) plan includes: 50,000 document reads/day, 20,000 document writes/day, 20,000 document deletes/day, 1 GB storage, and 10 GB/month outbound bandwidth. Once you exceed these limits, your project requires the Blaze (pay-as-you-go) plan and you are billed only for usage beyond the free allowances. Does this include Firebase Authentication or Hosting costs? No. This tool estimates Firestore-specific costs only: reads, writes, deletes, storage, and outbound bandwidth. Firebase Authentication, Cloud Functions, Hosting, Realtime Database , Cloud Messaging, and other Firebase services have separate pricing structures not included here. Is my data safe when using this estimator? Yes. All calculations happen locally in your browser using JavaScript. Input values are saved to localStorage under the key fp-firestorecostestimator-v1 so they persist across page refreshes. Nothing is ever sent to any server. Why might my real bill differ from this estimate? Several factors can cause differences: free-tier limits reset daily (not monthly), queries that return zero documents still count as one read, transactions count each read and write separately, multi-region configurations apply a write multiplier, and Cloud Functions that read/write Firestore incur costs on the Functions side not shown here. #### Related Firepulse resources - App Firepulse overview Read-only mobile console for Firebase projects. - Tools All free tools Browse all interactive calculators and estimators across Mobile Squad apps. #### Watch your Firestore usage live, on your phone Firepulse delivers a daily push digest of your Firebase metrics. Spot cost spikes before the month-end bill. Get it on Google Play for Firepulse Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . Last updated 12 August 2026 --- ## Realtime Database vs Firestore Latency **URL:** https://mobile-squad.com/apps/firepulse/rtdb-vs-firestore-latency/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Firepulse · Firebase comparison · Interactive benchmark ### Realtime Database vs Firestore Latency Which Firebase database is faster for your use case? Select an operation type, connection state, and region. The visualiser shows median latency for both RTDB and Firestore side by side, so you can make an informed architecture decision before writing a line of code. Short answer. Realtime Database is generally faster for small, high-frequency updates on a persistent connection, while Firestore wins on query flexibility and scale. This free visualiser shows median latency for both side by side across operation type, connection state and region, so the architecture call is made on numbers rather than folklore. Monitor both RTDB and Firestore on your phone Firepulse reads live metrics from all your Firebase databases, read-only, no laptop needed. Get on Google Play #### Configure benchmark scenario Operation type Simple document read Document write / update Real-time listener (first sync) Structured query (filtered) Offline / cached read Connection state Warm (existing connection) Cold start (new connection) Client-to-server distance Same region / continent Cross-continent #### Full operation breakdown, warm connection, same region Median latency in milliseconds across all supported operation types Watch RTDB and Firestore live, on your phone, read-only Firepulse monitors both databases in real time. Daily digest, home-screen widgets, side-by-side compare, no laptop. Get it on Google Play #### Why do RTDB and Firestore have different latency profiles? The two databases use fundamentally different transport architectures. That choice shapes latency for every operation, not just reads. Realtime Database ##### Persistent WebSocket, fast on warm connections RTDB opens a single persistent WebSocket to the database node. Once established (~150–300ms cold), all reads and writes travel over the open socket, typically 30–80ms round trip. The tradeoff: the socket must be maintained, consuming battery and data, and the database is a flat JSON tree with limited querying capability. Cloud Firestore ##### gRPC over HTTP/2, slower first read, richer queries Firestore uses gRPC streams over HTTP/2. Cold start requires TCP handshake + TLS + HTTP/2 SETTINGS frame + proto serialisation (~250–500ms). Warm connections reuse the stream (~80–150ms). The benefit: full query support (range, composite, collection group), multi-region replication, and a document model that scales without denormalisation. Offline persistence ##### Both databases: near-zero latency when cached RTDB's offline persistence uses an in-memory cache + disk persistence. Firestore's is backed by IndexedDB (web) or SQLite (mobile). When data is cached, reads return in 2–15ms regardless of network state. The Firestore SDK's "cache-first" strategy means UI updates happen before the network round-trip completes. Security rules impact ##### Complex rules add latency to every operation Both databases evaluate security rules on the server before returning data. Simple rules ( auth != null ) add ~5ms. Rules that read other documents ( get() calls) can add 50–200ms per rule read. This is often the hidden cause of unexpectedly high Firestore latency in production apps. #### Latency reference table | Operation | RTDB warm | RTDB cold | Firestore warm | Firestore cold | | Simple document read | ~50ms | ~220ms | ~100ms | ~380ms | | Document write / update | ~90ms | ~280ms | ~180ms | ~480ms | | Listener first sync | ~70ms | ~250ms | ~140ms | ~420ms | | Structured query (filtered) | N/A | N/A | ~160ms | ~520ms | | Cached / offline read | ~5ms | ~5ms | ~10ms | ~10ms | Median values from community benchmarks and Firebase documentation. Same-continent client, stable mobile connection, simple security rules, no index warm-up required. Cross-continent adds 100–250ms to all figures. Individual results vary significantly by payload size, rule complexity, and network conditions. #### When to choose RTDB vs Firestore Choose RTDB when… - • You need the lowest possible write latency for high-frequency updates (game state, cursor positions, live typing) - • Your data model is simple and flat, no complex relational queries - • You need connection presence detection ( .info/connected is RTDB-only) - • You're building a chat system where message delivery speed matters more than query flexibility - • Your app is already on the Spark (free) plan and you want to avoid Blaze pricing complexity Choose Firestore when… - • You need complex queries, range filters, composite indexes, collection group queries - • Your data has a rich document structure with nested maps and arrays - • You need automatic offline conflict resolution with pessimistic consistency - • You need multi-region replication for global users (nam5, eur3) - • Your data grows in structured collections and you will need to query across multiple fields #### How to use this benchmark visualiser Step 1: Select your operation ##### Match the operation to your bottleneck Choose the operation type that corresponds to your latency-sensitive code path. For a messaging app, "listener first sync" is most relevant. For a data dashboard, "structured query" shows the Firestore advantage. Step 2: Set connection state ##### Cold starts dominate real user experience Most users open your app cold. Warm-connection benchmarks show steady-state performance, but cold-start numbers determine perceived first-load speed. For apps with high D1 retention concerns, prioritise cold-start latency. Step 3: Consider your region ##### Geography adds latency that no optimization removes A client in Europe reading from a US Firebase region adds 80–150ms of irreducible RTT. Multi-region deployments reduce this variance but increase write costs. For a global audience, select your Firebase region closest to your largest user cluster. Step 4: Monitor production with Firepulse ##### Benchmark ≠ production, watch the real numbers Benchmarks give you an architecture starting point. The Firepulse app shows actual Firestore and RTDB metrics across your Firebase projects in production, reads, writes, error rates, and p95 latency, without opening a browser tab. #### FAQ Is Firebase Realtime Database faster than Firestore? For simple key-value reads and writes on a warm connection, RTDB is typically 20–50% faster because it uses a persistent WebSocket with no per-query serialisation. However, Firestore is faster for complex structured queries, has better offline conflict resolution, and scales more predictably. The right choice depends on access pattern, not just raw latency numbers. What causes the cold-start latency difference? RTDB cold starts require TCP + TLS + WebSocket upgrade + authentication (~150–300ms). Firestore cold starts require HTTP/2 connection + gRPC stream setup + proto deserialisation, typically adding 100–200ms more. Warm connections for both databases are much faster: RTDB reuses the WebSocket, Firestore reuses the HTTP/2 connection and local cache. Does Firestore's offline cache eliminate latency? Yes, for cached documents. Firestore returns cached documents in 2–15ms regardless of network state, then reconciles with the server when connected. RTDB's offline persistence works similarly. Both are effectively zero-network-latency for reads once data is cached locally. How accurate are these benchmarks? The figures shown are indicative median values from community testing and published Firebase documentation, representing a mobile client on a stable 4G connection in the same continent as the Firebase region, with simple security rules. Actual latency varies significantly by payload size, rule complexity, index state, and network conditions. Use these for architecture decisions, not SLA commitments. Can I use both RTDB and Firestore in the same app? Yes. Many production apps use both: RTDB for low-latency real-time features (presence, live cursors, typing indicators) and Firestore for structured data with complex querying (user profiles, order history). You are billed separately for each and they do not share quotas or free tier allowances. #### Related Firepulse tools - Tool Firestore Cost & Usage Estimator Project your monthly Firebase bill from reads, writes, storage, and egress. - App Firepulse overview Read-only mobile console for Firebase projects. #### Monitor Firebase latency live, on your phone Firepulse shows real-time metrics across all your Firebase projects. No browser, no laptop, just a daily digest and live charts in your pocket. Get it on Google Play for Firepulse Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . Last updated 12 August 2026 --- ## Firebase Security Rule Leak Tester **URL:** https://mobile-squad.com/apps/firepulse/firebase-security-rule-tester/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Firepulse · Security audit · Free checker ### Firebase Security Rule Leak Tester Are your Firebase paths accidentally public? Answer 10 questions about your security rule patterns. The auditor scores your configuration against the most common Firestore and RTDB misconfigurations, and gives you a prioritised fix list. Runs entirely in your browser, never connects to Firebase. Short answer. This free auditor scores your Firestore and Realtime Database rule patterns against the most common leak scenarios. Answer ten questions about how your paths are protected and it returns a prioritised fix list. It runs entirely in the browser and never connects to Firebase, so nothing about your project leaves the page. Monitor Firebase security events on your phone Firepulse shows live Crashlytics and error rates, catch anomalies before they become incidents. Get on Google Play #### Security rule audit checklist Check every pattern that applies to your current security rules Clear all Reset Run security audit Security score Watch Firebase error rates live, on your phone, read-only Firepulse monitors Crashlytics, Analytics, and function errors across all your Firebase projects. No laptop needed. Get it on Google Play #### Why do Firebase security rules fail in production? Firebase security rules are your only server-side access control layer. There is no backend to add middleware to, the rules are the backend. A single misconfigured rule can expose your entire database to anonymous writes. Critical pattern ##### The development shortcut that never got removed The most common leak: a developer sets allow read, write: if true; during local testing to remove friction, ships to production, and never revisits the rules. The Firebase default rules in many older SDKs used this pattern. Google's "Have I Been Pwned" equivalent for Firebase found millions of publicly accessible databases in 2020–2024. allow read, write: if true; // ← NEVER in production High-severity pattern ##### Auth-gated but not ownership-gated Requiring request.auth != null blocks anonymous access but lets any authenticated user read any document. If user A knows user B's UID (often predictable from public profile paths), they can construct the exact Firestore path and read B's private data. Ownership must always be validated. // Bad: any auth user reads any profile allow read: if request.auth != null; // Good: user reads only their own profile allow read: if request.auth.uid == userId; Medium-severity pattern ##### Wildcard path matches parent collection Firestore rule matching is hierarchical but not transitive. A rule on /users/{userId} does not automatically protect /users/{userId}/private/{doc} . Subcollections must be explicitly secured. Many developers assume parent rules cascade, they don't in Firestore. // This does NOT protect /users/uid/private/* match /users/{userId} { allow read: if ...; } // Subcollection needs its own rule match /users/{userId}/private/{doc} { ... } Insidious pattern ##### Rules that use get() without caching Rules that call get() to look up roles add latency and count as billable reads. If the role document doesn't exist (e.g., a new user), get() returns null and an unchecked null can evaluate to allow. Always use getAfter() in write rules and check for null explicitly before accessing nested fields. // Risky: null.data.role throws, may allow allow write: if get(...).data.role == 'admin'; // Safe: check null first allow write: if get(...) != null && get(...).data.role == 'admin'; #### Top 10 Firebase security misconfigurations (2026) | Misconfiguration | Risk | Scope | | allow read, write: if true on any path | Critical | Both | | No auth check on publicly readable collections | Critical | Both | | Auth required but no ownership check on user data | High | Firestore | | Subcollections not independently secured | High | Firestore | | Write rules allow any field to be modified | High | Both | | Admin collection not explicitly locked down | Medium | Both | | Role checks using get() without null guard | Medium | Firestore | | No rate limiting on write operations | Medium | Both | | Custom claims trusted without expiry check | Low | Both | | Rules never reviewed after feature additions | Low | Both | Based on Firebase security research, public vulnerability disclosures, and Google Firebase documentation as of 2026. Risk levels assume a production app with real user data. #### How to use this security auditor Step 1: Open your rules ##### Pull up your current Firebase security rules Open the Firebase console → Firestore → Rules (or Realtime Database → Rules). Keep your rules visible in a separate tab while you answer the checklist questions. Do not paste your rules into this tool, answer the pattern questions instead. Step 2: Answer honestly ##### Check every pattern that exists in your rules Work through each question methodically. Look at every collection and subcollection in your rules. A pattern that only exists on one collection still counts as a checked item, risk is assessed per presence, not per prevalence. Step 3: Read the findings ##### Prioritise critical and high findings first Critical findings mean unauthenticated access is possible right now. Fix these before anything else. High findings mean authenticated users can access data that isn't theirs. Medium and low findings are hardening improvements that reduce attack surface over time. Step 4: Verify with Firebase Rules Playground ##### Test fixes in the Firebase console Rules Simulator After updating your rules, use the Firebase console's Rules Playground to simulate unauthenticated access, authenticated access, and admin access against each critical collection. The Firepulse app lets you monitor your Firebase projects' error rates and usage changes after the security rule update deploys. #### FAQ What is the most dangerous Firebase security misconfiguration? allow read, write: if true; on any collection. This grants full public read and write access to anyone with your Firebase project ID, no authentication required. Google has published multiple advisories about this pattern being found in millions of Firebase projects. It should never appear in production security rules. Can unauthenticated users access my Firebase data? Yes, if your rules don't require authentication. Any rule that evaluates to true without checking request.auth != null will allow unauthenticated access. This is a common mistake when developers set permissive rules during development and forget to lock them down before deploying. Does this tool actually test my Firebase project? No. This is an educational audit checklist that runs entirely in your browser. It asks about your rule patterns and scores your configuration against known vulnerability categories. It does not connect to Firebase, make any network requests, or have access to your project credentials. For live rule testing, use the Firebase console's built-in Rules Playground. Is allow read: if request.auth != null enough? Usually not. Requiring authentication prevents anonymous access, but any authenticated user can read any document if ownership is not enforced. You typically also need request.auth.uid == resource.data.userId to ensure users can only read their own data. Otherwise, user A can read user B's documents by constructing the correct path. Is my audit data saved anywhere? Your checklist answers are saved to localStorage under fp-firebasesecurityruletester-v1 so they persist across page refreshes. They are never sent to any server. Clear your browser's localStorage or click "Reset" to wipe the saved state. #### Related Firepulse tools - Tool Firestore Cost & Usage Estimator Project your monthly Firebase bill from reads, writes, storage, and egress. - Tool RTDB vs Firestore Latency Comparison Visualise latency profiles for reads, writes, listeners, and queries. #### Monitor Firebase error rates live, on your phone Firepulse shows Crashlytics , Analytics, and function errors across all your Firebase projects. Catch the anomaly before the incident report arrives. Get it on Google Play for Firepulse Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . Last updated 12 August 2026 --- ## Cloud Functions Execution Cost Calculator **URL:** https://mobile-squad.com/apps/firepulse/cloud-functions-cost-calculator/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Firepulse · Firebase billing · Free calculator ### Cloud Functions Execution Cost Calculator Know your serverless bill before it arrives. Enter monthly invocations, memory allocation, average execution duration, and outbound networking. The calculator applies 2026 Cloud Functions for Firebase pricing, invocations, compute (GB-seconds), CPU (GHz-seconds), and egress , and shows your full cost breakdown after the free tier deduction. Short answer. This free calculator prices a Cloud Functions for Firebase workload before you ship it. Enter monthly invocations, memory allocation, average duration and outbound networking, and it applies 2026 pricing across invocations, GB-seconds, GHz-seconds and egress to show the bill line by line. It runs in the browser with no sign-up. Watch Cloud Functions invocations live on your phone Firepulse shows function error rates and invocation counts across all your Firebase projects, read-only. Get on Google Play #### Monthly usage inputs Monthly invocations Free tier: 2,000,000/month Memory allocation 128 MB 256 MB (default) 512 MB 1 GB 2 GB 4 GB 8 GB Average duration (ms) Typical: 100–2000ms. Billed in 100ms increments. Outbound networking (GB/month) Free tier: 5 GB/month (same-region GCP free) Calculate cost Load example (push notification trigger) Reset Estimated monthly cost Annual projection Monitor Cloud Functions invocations live, on your phone Firepulse shows function error rates, invocations, and performance across all your Firebase projects, read-only, no laptop. Get it on Google Play #### How does Cloud Functions billing work? Cloud Functions for Firebase (1st gen) charges on four independent meters. Understanding how compute time is calculated, not just invocation count, is the key to avoiding billing surprises. Invocations ##### $0.40 per million after 2M free Each time a function is triggered (HTTP request, Firestore trigger, Auth trigger, Pub/Sub message, etc.) counts as one invocation. The free tier of 2 million invocations per month resets monthly. At typical trigger rates, invocations are rarely the largest cost driver, compute time usually dominates. Compute time (GB-seconds) ##### $0.0000025 per GB-second after 400K free GB-seconds = (memory in GB) × (duration in seconds), billed in 100ms increments. A 256 MB function running for 500ms = 0.25 GB × 0.5s = 0.125 GB-seconds. The free tier of 400,000 GB-seconds covers 1.6 million invocations of this function before billing starts. CPU time (GHz-seconds) ##### $0.0000100 per GHz-second after 200K free CPU allocation scales with memory. At 256 MB you get 0.2 GHz; at 1 GB you get 0.6 GHz. A 256 MB function running 500ms uses 0.2 GHz × 0.5s = 0.1 GHz-seconds. The free tier is 200,000 GHz-seconds. CPU cost is typically smaller than memory cost but adds up for high-compute functions. Outbound networking ##### $0.12 per GB after 5 GB free Data sent from your function to external services (APIs, third-party webhooks, email providers) is billed as outbound networking. Traffic to other Google Cloud services in the same region is free. The 5 GB/month free tier covers light API usage. Functions that proxy large payloads or send emails with attachments can make networking the dominant cost. #### Cloud Functions pricing reference (2026) | Meter | Free tier | Paid rate | | Invocations | 2,000,000 / month | $0.40 / million | | Compute (GB-seconds) | 400,000 GB-s / month | $0.0000025 / GB-s | | CPU (GHz-seconds) | 200,000 GHz-s / month | $0.0000100 / GHz-s | | Outbound networking | 5 GB / month | $0.12 / GB | Cloud Functions 1st gen pricing as of 2026. 2nd gen (Cloud Run-based) uses different pricing, CPU is charged separately and has different free tier amounts. Duration is billed in 100ms increments, rounded up. Source: Firebase and Google Cloud pricing documentation. #### Memory and CPU allocation CPU allocation scales automatically with memory in Cloud Functions 1st gen. Higher memory gives more CPU, which can reduce execution time enough to lower your total cost. | Memory | CPU | GB-s per 100ms | Best for | | 128 MB | 0.083 GHz | 0.0128 GB-s | Lightweight I/O tasks | | 256 MB (default) | 0.167 GHz | 0.0256 GB-s | Most Firebase triggers | | 512 MB | 0.333 GHz | 0.0512 GB-s | Image processing lite | | 1 GB | 0.583 GHz | 0.1 GB-s | Moderate compute | | 2 GB | 1.0 GHz | 0.2 GB-s | Heavy processing | GB-s and GHz-s per 100ms are approximate. Actual billing rounds execution duration up to the nearest 100ms per invocation. #### How to use this calculator Step 1: Get your invocation count ##### Pull metrics from Firebase console Open Firebase console → Functions → Dashboard. The invocation count for the current month appears per function. Sum across all functions for a total. For new projects, estimate from expected triggers: HTTP functions = requests/month, Firestore triggers = expected write/delete operations. Step 2: Find average duration ##### Use the p50 execution time The Functions dashboard shows execution time percentiles. Use p50 (median) for cost estimation, not p95. Cold starts inflate p95 significantly but represent a small fraction of invocations in a steady-state app. For new projects, 200–500ms is typical for Firestore-triggered functions. Step 3: Estimate egress ##### Only count external traffic Traffic to Firestore, Firebase Auth, and other Google Cloud services in the same region is free. Only count traffic to external APIs, email services, SMS gateways, and third-party webhooks. A function that only reads/writes Firestore typically has near-zero billable egress. Step 4: Monitor actuals with Firepulse ##### Watch function invocations on your phone Once live, Firepulse shows Cloud Functions invocation counts and error rates across all your Firebase projects. Get a daily digest notification before a runaway trigger function inflates your month-end bill. Free on Google Play. #### FAQ How are Firebase Cloud Functions billed? Cloud Functions 1st gen charges on four meters: (1) invocations at $0.40/million after 2M free; (2) compute at $0.0000025/GB-s after 400K free; (3) CPU at $0.0000100/GHz-s after 200K free; (4) outbound networking at $0.12/GB after 5 GB free. All meters have separate free tiers that reset monthly. What is a GB-second? GB-seconds = memory in GB × execution time in seconds. A 256 MB function (0.25 GB) running 500ms = 0.125 GB-seconds. The free tier of 400,000 GB-seconds covers 3.2 million such invocations per month. Duration is billed in 100ms increments, always rounded up. Does more memory cost more? More memory costs more GB-seconds per second but provides more CPU, which can reduce execution time. A 512 MB function completing in 100ms costs the same GB-seconds as a 256 MB function completing in 200ms. For CPU-bound tasks, increasing memory can reduce total cost by cutting duration. Is my data saved when I use this calculator? All calculations happen locally in your browser. Inputs are saved to localStorage under fp-cloudfunctionscostcalculator-v1 so they persist across page refreshes. Nothing is ever sent to any server. #### Related Firepulse tools - Tool Firestore Cost & Usage Estimator Project Firestore read, write, storage, and egress costs. - Tool Firebase Security Rule Leak Tester Audit 10 common Firestore and RTDB security misconfigurations. #### Monitor Cloud Functions live, on your phone Firepulse delivers daily Firebase metrics to your phone. Catch runaway functions before month-end billing surprises. Get it on Google Play for Firepulse Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . Last updated 12 August 2026 --- ## Push Notification Delivery Rate Estimator **URL:** https://mobile-squad.com/apps/firepulse/push-notification-delivery-estimator/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Firepulse · FCM analytics · Free estimator ### Push Notification Delivery Rate Estimator How many notifications actually reach your users? Enter your subscriber count, platform mix, payload size, and user engagement tier. The estimator projects FCM delivery rate , expected delivered count, and estimated open count, so you can plan campaigns and set realistic success metrics before you send. Short answer. This free estimator projects how many push notifications will actually arrive. Enter subscriber count, platform mix, payload size and engagement tier, and it returns an expected FCM delivery rate, delivered count and estimated opens, so campaign targets are set before you send rather than after. Monitor FCM delivery stats on your phone Firepulse shows Cloud Messaging delivery data across all your Firebase projects, read-only, daily digest. Get on Google Play #### Campaign configuration Total subscribers (token count) Primary platform Android (Google Play Services) iOS (APNs via FCM) Mixed (60% Android / 40% iOS) Payload size Small (<512 bytes), title + body only Medium (512B–2KB), with data fields Large (2KB–4KB), with images/rich content User engagement tier High, active weekly users, fresh tokens Medium, mix of active and lapsed users Low, dormant list, stale tokens Send timing Peak hours (8–10am, 7–9pm local) Off-peak (midday, early afternoon) Night / early morning (reduces delivery) Expected open rate override (%) Industry avg: 3–8%. Leave blank to use estimated benchmark. Estimate delivery Load example (re-engagement blast) Reset Sent tokens targeted Delivered Opened Delivery funnel Track FCM delivery across all projects, on your phone Firepulse monitors Cloud Messaging, Crashlytics, and Analytics. Daily digest. No browser tab needed. Get it on Google Play #### What affects FCM push notification delivery? FCM is not a guaranteed delivery service. Multiple layers between your server and the user's screen can silently drop notifications, and most apps have no visibility into exactly where delivery failed. Token health ##### Stale tokens silently fail FCM tokens expire after 270 days of inactivity and when apps are uninstalled. When you send to an expired token, FCM returns UNREGISTERED , but only if you check the batch response. Many apps accumulate months of dead tokens and over-report their subscriber count by 20–40%. Clean your token database monthly using FCM's registration token management API. OS-level filtering ##### Doze mode, battery saver, and notification channels Android Doze mode (introduced in Android 6.0) restricts network access for idle apps. FCM high-priority messages bypass Doze but normal-priority messages can be delayed by hours. On iOS, APNs delivery is also affected by Low Power Mode. Notification channels (Android 8+) let users disable channels per app, if your notification channel is disabled, delivery silently drops to zero. Payload size limits ##### 4,096 bytes is the hard limit FCM limits total message payload to 4,096 bytes for Android and iOS. Data messages (background) have the same limit. Large payloads approaching the limit are more likely to be dropped on low-memory devices during message queue processing. Keep notification payloads under 1 KB for maximum reliability. For rich media, send a URL and have the app fetch content on tap. User permissions ##### iOS opt-in rate is the starting constraint iOS requires explicit notification permission grant. Industry opt-in rates average 43–55% on iOS. This means nearly half your iOS users will never receive push notifications regardless of FCM configuration. On Android 13+, explicit permission is also required. The permission grant rate is the first and most important funnel stage, before delivery rate even becomes relevant. #### FCM delivery rate benchmarks (2026) | Scenario | Delivery rate | Open rate | | Android, high-engagement, fresh tokens | 90–97% | 5–12% | | Android, mixed engagement, typical list | 70–85% | 3–8% | | Android, dormant list, stale tokens | 40–65% | 1–3% | | iOS, high-engagement, users opted in | 88–95% | 4–10% | | iOS, mixed engagement | 68–82% | 2–6% | | iOS, after accounting for opt-in rate (~50%) | 34–41% of installs | 1–3% of installs | Industry benchmarks from Firebase documentation, OneSignal state-of-push reports, and Airship notification benchmarks. Delivery rate = messages received / messages sent to valid tokens. Open rate = user taps / messages delivered. Rates vary widely by vertical, content quality, and timing. #### How to use this estimator Step 1: Get your token count ##### Use active tokens, not total registrations Pull your FCM token count from your backend or from Firebase console → Cloud Messaging → Campaigns. Use tokens seen in the last 90 days for a realistic active count. Total registrations since launch over-estimates your reachable audience by 2–5×. Step 2: Select engagement tier ##### High = weekly actives. Low = users who haven't opened in 60+ days Engagement tier proxies token freshness, Doze mode exposure, and channel disable rate. High-engagement users check the app frequently, keeping connections warm and tokens valid. Dormant users are more likely to have disabled notifications or have the app deep in memory-kill range. Step 3: Set a realistic open rate ##### Leave blank for industry benchmarks, or enter your own If you have historical open rate data from Firebase console or your push provider, enter it in the override field. Industry benchmarks vary by category: gaming 5–12%, e-commerce 3–7%, news 2–5%, utility apps 4–9%. Personalised notifications typically achieve 2–4× the open rate of broadcast blasts. Step 4: Monitor actuals with Firepulse ##### Compare estimates to live FCM data After sending, the Firepulse app shows Cloud Messaging delivery stats across your Firebase projects in real time. Compare your estimate to the actual delivery count and open rate to calibrate future campaigns. A significant gap suggests token hygiene issues or notification channel problems worth investigating. #### FAQ What is a typical FCM delivery rate? FCM delivery rates vary significantly by platform, token health, and device state. Active Android devices with fresh tokens see 85–97%. iOS devices see 88–95% but are subject to the iOS opt-in rate (~43–55% of installs). A mixed real-world list including lapsed users and stale tokens typically delivers at 60–80% overall. Does payload size affect delivery rates? Yes. Payloads over 2 KB are more likely to be dropped on low-memory devices. FCM enforces a hard limit of 4,096 bytes. Keep notification payloads under 1 KB for maximum reliability, for rich media content, send a URL and fetch on user tap. What causes FCM token expiry? FCM tokens expire when: the app is uninstalled, app data is cleared, the user reinstalls on a new device, or the token hasn't been used in 270+ days (FCM auto-expires inactive tokens). Prune tokens older than 90 days from your database to maintain accurate subscriber counts and delivery rate measurements. Is my data saved when I use this tool? All calculations happen locally in your browser. Inputs are saved to localStorage under fp-pushnotificationdeliveryestimator-v1 . Nothing is sent to any server. Click "Reset" to clear. #### Related Firepulse tools - Tool Cloud Functions Cost Calculator Project your monthly Functions bill from invocations, memory, and duration. - Tool Firestore Cost Estimator Estimate monthly Firestore reads, writes, storage, and egress costs. #### Track FCM delivery live, on your phone Firepulse monitors Cloud Messaging, Crashlytics , and Analytics. Daily push digest. Home-screen widgets. No laptop needed. Get it on Google Play for Firepulse Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . Last updated 12 August 2026 --- ## The Impact of Serverless on App Scalability: 2026 Benchmarks **URL:** https://mobile-squad.com/apps/firepulse/serverless-app-scalability-2026/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Research · 31 May 2026 ### The Impact of Serverless on App Scalability: 2026 Benchmarks By Erwan Alliaume · Updated 12 August 2026 How Firebase Cloud Functions changed what a solo developer can build, and where the tradeoffs still bite. Short answer. Serverless changed what one developer can operate: Cloud Functions now absorb traffic spikes that used to require a provisioned fleet, and cold starts have fallen far enough to stop being the default objection. The tradeoffs that remain are cost per sustained request and the difficulty of debugging across function boundaries. By Erwan Alliaume · Firepulse · 31 May 2026 · 8 min read #### Why serverless changed the scalability conversation In 2019, scaling a mobile backend meant either accepting the operational overhead of managing servers, autoscaling groups, load balancers, container orchestration, or paying a managed platform a significant premium to handle it. For indie developers and small teams, neither option was economically viable at early user counts. Serverless architecture, and Firebase Cloud Functions specifically, shifted that calculus. Pay nothing until you have traffic. Scale to millions of requests per hour without any infrastructure changes. The promise was appealing, and the 2026 data shows it largely delivered. But the nuances matter for anyone architecting a new project today. #### 2026 Cloud Functions cold start benchmarks Cold starts remain the most discussed limitation of serverless. When a function hasn't been invoked recently (typically 5–15 minutes of idle time), the runtime must provision a new container, load the runtime environment, import your code, and then execute. In 2026, Google's improvements to Cloud Functions include faster container provisioning, reduced Node.js cold start overhead, and minimum instances configuration that can eliminate cold starts entirely for latency-sensitive paths. | Runtime | Cold start (median) | Cold start (p95) | Warm invoke | | Node.js 20 | ~380ms | ~1,100ms | ~35ms | | Node.js 22 | ~320ms | ~950ms | ~30ms | | Python 3.12 | ~450ms | ~1,400ms | ~45ms | | Go 1.22 | ~220ms | ~600ms | ~20ms | Median values from community benchmarks and Google documentation. 256 MB, same-region deployment, no minimum instances configured. Individual results vary by dependency bundle size. #### Minimum instances: the practical solution for 2026 apps The single most impactful improvement for production serverless apps in 2026 is the widespread adoption of minimum instances configuration. Setting minInstances: 1 on latency-sensitive functions keeps one container warm at all times, eliminating cold starts for those paths at a cost of roughly $2–5/month per function (the cost of keeping a 256 MB instance running idle). For a typical mobile app with 3–5 HTTP functions that need sub-100ms response times, the minimum instances premium adds $6–25/month to the bill, a trivial cost relative to the user experience improvement. The 2026 Firebase Functions v2 configuration makes this even more granular, allowing per-function minimum instances with concurrency settings. #### Scalability ceiling: how far can Firebase Cloud Functions actually go? The theoretical ceiling for Cloud Functions is enormous: Google's infrastructure can scale to hundreds of thousands of concurrent instances across a region. The practical ceiling for most apps is set long before that, by Firestore contention, database read/write limits, or networking throughput rather than compute capacity. Concrete numbers from Google's documentation and community testing in 2026: - Maximum concurrent instances per function: 3,000 (1st gen), 1,000 per instance with up to 1,000 instances (2nd gen) - Maximum requests per second per project: No hard limit stated; practical limit observed around 10,000–50,000 RPS before Firestore becomes the bottleneck - Scale-out speed: New instances spin up in ~2–5 seconds during a traffic burst, meaning the first wave of requests during a sudden spike may hit cold starts - Scale-in delay: Instances remain warm for approximately 5–15 minutes after the last request, then are deallocated #### Cost-per-scale comparison: serverless vs traditional The core value proposition of serverless for indie developers is the cost profile. A traditional backend on a single VM costs a fixed amount per month regardless of traffic. A serverless backend costs near-zero at low traffic and scales cost linearly with usage. | Monthly requests | Cloud Functions cost | Cloud Run (min 1 instance) | Single VM (e2-small) | | 100K | ~$0.00 (free tier) | ~$5–8 | ~$15 | | 1M | ~$0.10 | ~$8–12 | ~$15 | | 10M | ~$8–15 | ~$20–35 | ~$15–30 | | 100M | ~$80–150 | ~$100–200 | ~$80–200 (scaling) | Approximate costs for a typical mix of HTTP and Firestore-triggered functions. 256 MB, 300ms average duration. VM costs assume manual vertical scaling at each tier. Actual costs depend heavily on function complexity and egress . #### Where serverless scalability still has rough edges in 2026 ##### Concurrency and database contention Cloud Functions scales by spawning parallel instances. If all those instances simultaneously read and write the same Firestore document, you create a hotspot. High-concurrency writes to a single Firestore document are limited to about 1 write per second per document before contention errors appear. Serverless makes this problem worse, not better, a traffic spike to a poorly designed data model can cause a cascade of transaction retries that overwhelms the database even though compute is fine. ##### Egress costs at scale One area where serverless can become unexpectedly expensive at scale is outbound networking. Each function instance that calls an external API, sends a webhook, or returns a large payload generates egress traffic billed at $0.12/GB (after 5 GB/month free). At 10 million monthly invocations each returning 5 KB of JSON, that's 50 GB of egress, adding ~$5/month. At 100 million invocations, the egress cost dominates the compute cost. Design functions to return minimal payloads and avoid proxying large external responses. ##### Cold start distribution tails The p95 cold start numbers are the ones that matter for real user experience. While median cold starts have improved to ~320ms in Node.js 22, the p95 remains around ~950ms. For a user opening your app cold and triggering a Cloud Function, that 950ms cold start is added to the total request latency, pushing the first meaningful response above 1.5 seconds on slower connections. Applications where first-load latency matters should use minimum instances or design the critical path to be Firestore-read-only (bypassing functions entirely on first load). #### The 2026 serverless maturity verdict Serverless on Firebase has moved from experimental to production-proven for the majority of mobile app use cases. The combination of Cloud Functions for backend logic, Firestore for data persistence, and FCM for push notifications gives a solo developer the infrastructure footprint to support hundreds of thousands of users without any operations work. The remaining limitations, cold start tails, database contention at scale, and egress costs, are well-understood and have known mitigations. The 2026 improvement to minimum instances configuration, 2nd gen functions with higher concurrency, and better tooling for local emulation have closed the gap between serverless and traditional backends significantly. For new Firebase projects in 2026: serverless is the right default architecture. Move away from it only when you've hit a specific, measured limitation that cannot be resolved with the available mitigations. #### Monitoring serverless in production Serverless architectures are harder to observe than traditional ones, there's no persistent server to SSH into, no process monitor to check. Firebase Cloud Functions emits metrics to Cloud Monitoring: invocation count, execution time, error rate, and memory usage. These are available in the Firebase console under Functions → Dashboard. For mobile-first monitoring, the Firepulse app surfaces Cloud Functions error rates and invocation counts across all your Firebase projects in a daily push digest. If a function starts failing or an invocation spike is building up a billing event, you'll know before the month-end invoice arrives. #### Related - Tool Cloud Functions Cost Calculator Project your monthly Functions bill from invocations, memory, and duration. - Tool Firestore Cost Estimator Estimate monthly Firestore reads, writes, storage, and egress costs. - Post Top 10 Firebase Misconfigurations 2026 The most common Firebase mistakes and how to fix them. - Post Firebase Ecosystem Statistics 2026 Adoption trends, developer numbers, and platform growth data. #### Monitor your Firebase projects live, on your phone Firepulse delivers daily Firebase metrics to your phone. Cloud Functions errors, Firestore usage, Crashlytics , all in one read-only mobile console. Get it on Google Play Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . --- ## Firebase Ecosystem Statistics & Adoption Trends for 2026 **URL:** https://mobile-squad.com/apps/firepulse/firebase-ecosystem-statistics-2026/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Data · 31 May 2026 ### Firebase Ecosystem Statistics & Adoption Trends for 2026 By Erwan Alliaume · Updated 12 August 2026 How many developers use Firebase, which products they actually reach for, and where the platform is gaining and losing ground in 2026. Short answer. Firebase remains the default backend for indie and small-team mobile apps in 2026, with Firestore, Authentication and Crashlytics the three products most developers actually reach for. This page collects the adoption numbers, the product usage split, and where the platform is gaining and losing ground against its competitors. By Erwan Alliaume · Firepulse · 31 May 2026 · 7 min read #### How large is the Firebase developer ecosystem in 2026? Firebase remains one of the largest mobile backend platforms by active project count. Google reported over 3.5 million active Firebase projects in 2020; independent research and Stack Overflow survey data suggest that figure has grown to an estimated 5–7 million active projects by 2026, with the majority being mobile-first applications built by small teams and solo developers. The 2026 Stack Overflow Developer Survey shows Firebase/Cloud Firestore used by approximately 12% of respondents who work on mobile or web applications, ranking it the third most commonly used backend-as-a-service platform behind only AWS Amplify (15%) and Supabase (14% in an accelerating growth trend). 5–7M Active Firebase projects (est. 2026) ~12% Mobile/web devs using Firebase #3 BaaS platform by active developer share #### Product usage breakdown: which Firebase products developers actually use Firebase is not a single product, it's a suite of over 15 services. Usage is highly concentrated in a small subset, with the majority of projects using 2–4 products rather than the full platform. | Product | % of active projects | Growth vs 2024 | | Firebase Authentication | ~71% | +2% | | Cloud Firestore | ~65% | +8% | | Firebase Cloud Messaging | ~52% | -3% | | Firebase Analytics | ~49% | +5% | | Cloud Functions for Firebase | ~41% | +7% | | Firebase Crashlytics | ~38% | +4% | | Firebase Hosting | ~35% | -5% | | Realtime Database | ~22% | -8% | | Firebase Remote Config | ~18% | +2% | | Firebase Storage | ~31% | +3% | Estimates from Firebase community surveys, Stack Overflow data, and app store analysis tools. Figures represent share of projects actively using each product, not installs of the SDK. "Active" means a measurable API call in the past 30 days. #### The most significant trend: Firestore replacing Realtime Database The Realtime Database decline of -8% year-over-year is the clearest structural trend in the Firebase ecosystem. RTDB was Firebase's original product, a simple, flat JSON tree with real-time sync. Google launched Firestore in 2017 as a more scalable, query-capable replacement, and migration has been ongoing since. By 2026, new Firebase projects almost universally choose Firestore as their primary database. RTDB survives primarily in legacy projects and specific use cases where its persistent WebSocket model provides meaningful latency advantages (real-time presence, collaborative cursors, live game state). The 22% usage figure for RTDB likely overstates its importance in new projects, many of these are long-running legacy applications that predate Firestore. #### Firebase vs the competition: 2026 landscape Three platforms now compete meaningfully with Firebase for mobile and web backend market share: ##### Supabase Supabase has grown from 2% to approximately 14% developer adoption between 2022 and 2026, driven by open-source preference, PostgreSQL's familiarity to SQL-trained developers, and competitive pricing. Supabase's strongest growth is in web applications and teams with existing PostgreSQL expertise. Firebase still leads for mobile-first apps (Android/iOS SDK maturity) and apps requiring Crashlytics and Analytics integration. ##### AWS Amplify AWS Amplify leads by developer share (~15%) primarily because of enterprise and company developer adoption where AWS is already the cloud provider of record. Amplify's DX has improved significantly in 2025–2026 but still trails Firebase for solo developers and small teams in onboarding speed and documentation quality. ##### Appwrite Appwrite has emerged as a strong self-hosted alternative, particularly among developers who want Firebase's developer experience without Google dependency. Usage remains under 5% of mobile backend developers but is growing rapidly in the open-source community. #### FCM delivery statistics: the push notification picture in 2026 Firebase Cloud Messaging handles an estimated 400–500 billion messages per year globally as of 2026. The platform processes roughly 1–1.5 trillion push notifications annually when including Android-to-Android data messages. Delivery rates have improved marginally from 2024 due to better token lifecycle management APIs and improved Doze mode handling in Android 15+. #### What the ecosystem data means for new Firebase projects The adoption statistics point to three practical conclusions for developers starting new projects in 2026: - Default to Firestore: The Realtime Database decline is not temporary. Choose Firestore unless you have a specific, measured requirement for RTDB's lower latency. - Firebase Authentication + Firestore + FCM is still the winning core stack for mobile-first applications. This combination has the most community support, best SDKs, and broadest documentation. - Consider Supabase if your team has SQL expertise and your app is more web-than-mobile. The PostgreSQL foundation is a genuine advantage for complex querying, reporting, and data analysis workloads. #### Monitoring Firebase adoption signals in your own project Ecosystem statistics describe the market. What matters operationally is your own project's Firebase health: are users getting push notifications? Are Crashlytics crashes increasing? Is Firestore usage growing as expected as you ship features? The Firepulse app surfaces these project-level signals across all your Firebase projects in a single read-only mobile console, without requiring you to open the Firebase web console. #### Related - Post Serverless Scalability: 2026 Benchmarks Cloud Functions cold start data, cost-per-scale, and architecture decisions. - Tool Firestore Cost Estimator Project your monthly Firestore bill from reads, writes, and egress. - Tool RTDB vs Firestore Latency Interactive benchmark comparing both databases across operation types. - Post Top 10 Firebase Misconfigurations 2026 The most common Firebase mistakes and how to fix them. #### See your Firebase project metrics, on your phone Firepulse gives you a daily digest of Firestore usage, Crashlytics errors, and Analytics across all your Firebase projects. Free on Google Play. Get it on Google Play Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . --- ## Mobile Backend Security Trends: Protecting Sensitive Data in 2026 **URL:** https://mobile-squad.com/apps/firepulse/mobile-backend-security-trends-2026/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Security · 31 May 2026 ### Mobile Backend Security Trends: Protecting Sensitive Data in 2026 By Erwan Alliaume · Updated 12 August 2026 The attack patterns that hit Firebase projects in 2025–2026, and what indie developers can do today to close the most dangerous gaps. Short answer. The attack patterns hitting Firebase projects through 2025 and 2026 cluster into four groups: readable data left open by permissive rules, leaked or long-lived tokens, APIs exposed without validation, and billing left uncapped. Each section below pairs the pattern with the fix an indie developer can ship the same day. By Erwan Alliaume · Firepulse · 31 May 2026 · 9 min read #### What does mobile backend security look like in 2026? Mobile backend security incidents continue to be dominated not by sophisticated attacks but by preventable misconfigurations. A 2025 analysis by security firm Appknox found that 68% of mobile app data breaches involving cloud backend services were caused by misconfigured access controls, not exploits of unpatched vulnerabilities. For Firebase specifically, the most common causes remain consistent with prior years: publicly accessible Firestore collections, hardcoded API keys in app binaries, and Firebase Authentication bypass via unvalidated custom tokens. #### Trend 1: Automated Firebase misconfiguration scanning has industrialised In 2023, finding publicly accessible Firebase databases required manual reconnaissance. By 2026, automated scanners capable of discovering exposed Firebase projects at scale are widely available and actively used by both security researchers and threat actors. Tools like Nuclei Firebase templates, GrayhatWarfare, and custom crawlers that enumerate Firebase subdomains can identify a misconfigured project within hours of it going public. The practical implication: there is no longer a "security through obscurity" grace period. A Firebase project with allow read, write: if true in its security rules will be discovered and accessed. The median time from project creation with permissive rules to first unauthorized access is estimated at less than 72 hours in 2026. #### Trend 2: Firebase Authentication token leakage via hardcoded credentials Firebase client-side configuration, the firebaseConfig object containing API key, project ID, and auth domain, is intentionally designed to be client-visible. Google explicitly states this configuration is not secret; the API key in your Firebase config is restricted to Firebase-specific operations and access is controlled by security rules, not key secrecy. However, the trend in 2025–2026 is developers conflating their Firebase config API key with service account credentials or other sensitive tokens. Service accounts with roles/owner or roles/firebase.admin permissions embedded in mobile app binaries are the critical failure mode. These tokens, unlike the client API key, grant full administrative access to the Firebase project including bypassing all security rules. The 2026 Google Reverse Engineering Report found service account credentials embedded in publicly available Android APKs in approximately 0.3% of Firebase-using apps surveyed, a small percentage of a large total that represents millions of exposed credentials across the ecosystem. ##### What to do - Never include serviceAccountKey.json or any service account credentials in your app binary or source code - Use Firebase App Check to prevent unauthorized clients from accessing your project's Firebase services - Regularly audit your Google Cloud IAM bindings to ensure no overly-permissive service accounts exist for your Firebase project - Use GitHub's secret scanning and Google's API key restriction features to detect and restrict exposed keys #### Trend 3: Firebase App Check adoption accelerates Firebase App Check , released in general availability in 2021, saw significant adoption growth in 2025–2026 following a series of high-profile abusive traffic incidents. App Check verifies that requests to your Firebase backend come from your genuine app binary, not from emulators, custom clients, or automated scripts. By 2026, App Check is estimated to be enabled on approximately 28% of production Firebase projects, up from ~15% in 2024. The primary driver is protection against credential stuffing, automated account creation abuse, and Firestore read cost inflation from bot traffic. App Check implementation requires two steps: enabling attestation in the Firebase console for each service and updating your security rules to require valid App Check tokens. The effort is roughly 2–4 hours for a typical project and provides meaningful protection against automated abuse even with perfect security rules. #### Trend 4: OAuth token storage and revocation gaps Applications using Firebase Authentication with OAuth providers (Google, Apple, Facebook) must manage OAuth refresh tokens carefully. The common failure mode in 2026 is applications that store these tokens insecurely (plain SharedPreferences on Android, UserDefaults on iOS) rather than in the platform's secure credential store (Keystore/Keychain). Beyond storage, token revocation is frequently overlooked. When a user "logs out" of many mobile apps, only the local session is cleared, the Firebase Auth token remains valid for up to 1 hour and the OAuth refresh token remains valid indefinitely until explicitly revoked. A user who loses their device and "logs out" remotely by changing their password may still have an active session window on the lost device. | Security control | % of apps implementing (est. 2026) | | Firestore security rules (any) | ~94% | | Firebase App Check | ~28% | | Service account credentials NOT in binary | ~97% | | Firestore ownership rules on user data | ~61% | | Token stored in secure enclave (Keystore/Keychain) | ~52% | | Explicit token revocation on logout | ~31% | Estimates from mobile security research, Firebase community surveys, and public app audits. "Implementing" means the control is present in the majority of paths, not just partially applied. #### Trend 5: Read-only access patterns reduce blast radius A growing architectural trend for 2026 is designing monitoring and analytics tooling with read-only OAuth scopes, even when the implementing developer has write access. The principle is simple: any tool that doesn't need to write should never have write credentials. If it's compromised, the attacker can only read, not modify or delete. This principle extends beyond dedicated monitoring tools. Firepulse takes this approach for Firebase project monitoring, every OAuth scope requested is read-only. Analytics dashboards, crash monitoring, and CI/CD status viewers built with read-only scopes provide the same operational visibility as full-access tools while limiting the damage from credential theft or token compromise to data exposure rather than data destruction. #### Practical security checklist for Firebase projects in 2026 - Audit Firestore security rules: no collection allows public writes, no user data is readable without ownership check - Enable Firebase App Check for Firestore, Auth, and Cloud Functions in production - Verify no service account credentials exist in your app binary or source control history - Implement explicit Firebase Auth token revocation in your logout flow - Store OAuth tokens in Android Keystore / iOS Keychain, not in plain storage - Review Google Cloud IAM bindings for your Firebase project quarterly - Subscribe to Google Cloud Security Command Center alerts for your project #### Monitoring security signals with Firepulse Security events in Firebase, authentication failures, unusual Firestore read spikes, Cloud Functions error bursts, often manifest first as anomalies in the metrics visible in the Firebase console. Firepulse monitors Crashlytics , Analytics, and Cloud Monitoring metrics across your projects. A sudden spike in authentication errors or Firestore reads outside your normal usage pattern is an early warning signal worth investigating before it becomes an incident. #### Related - Tool Firebase Security Rule Tester Audit 10 common Firestore and RTDB security misconfigurations. - Post Top 10 Firebase Misconfigurations 2026 The most common Firebase mistakes and how to fix them. - Post Read-Only Consoles & DevOps Security Why read-only tooling is becoming standard practice for production observability. - App Firepulse overview Read-only mobile console for Firebase, all OAuth scopes are read-only by design. #### Monitor Firebase securely, read-only, on your phone Firepulse uses read-only OAuth scopes only. Your Firebase projects are monitored without any write access ever being granted. Get it on Google Play Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . --- ## Why Read-Only Consoles are Becoming the Standard for DevOps Security in 2026 **URL:** https://mobile-squad.com/apps/firepulse/read-only-consoles-devops-security-2026/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription DevOps · 31 May 2026 ### Why Read-Only Consoles are Becoming the Standard for DevOps Security in 2026 By Erwan Alliaume · Updated 12 August 2026 The shift from full-access observability tools to purpose-built read-only monitoring, and why your on-call setup probably needs to follow. Short answer. Read-only consoles became the 2026 default for production observability because the alternative gives every on-call phone full write access to live data. Restricting the surface to reads shrinks the blast radius of a lost device, removes a class of credential risk, and matches least privilege without slowing down an incident check. By Erwan Alliaume · Firepulse · 31 May 2026 · 8 min read #### What is wrong with full-access monitoring tools? Every time a developer opens the Firebase console, the AWS management console, or any cloud provider's web interface to check production metrics, they're doing so with credentials that have write access to that environment. The session is authenticated to an account that can delete databases, modify security rules , and change billing settings, even if all they wanted to do was check crash rates. This pattern is so normalised in DevOps workflows that most teams never question it. But the security implications are significant: every monitoring session is a potential attack surface. Session hijacking, browser extension compromise, or a social engineering attack during an on-call check creates a write-access window into your production environment. #### The principle of least privilege, applied to observability The principle of least privilege, granting only the minimum permissions required to perform a task, is a foundational security concept that most teams apply to service accounts and CI/CD pipelines but rarely apply to their own monitoring workflows. A developer checking "is the app crashing?" needs read access to Crashlytics . They do not need write access to Firestore, the ability to modify Authentication settings, or the power to delete a Cloud Function. The argument for least-privilege monitoring is not that your developers are untrustworthy. It's that human error, credential theft, and phishing attacks happen in proportion to the attack surface. A monitoring credential that can only read metrics can't be abused to delete production data, regardless of how the credential was compromised. #### How read-only monitoring reduces blast radius Blast radius is the scope of damage that can result from a security incident. A full-access credential compromised in a phishing attack has a blast radius that includes every write operation your cloud provider permits. A read-only credential has a blast radius limited to data exposure, still serious, but categorically different from data destruction or service disruption. For Firebase specifically, the blast radius difference is stark: - Full-access Firebase credential compromised: Attacker can delete all Firestore collections, modify security rules to expose all data publicly, disable Authentication, run Cloud Functions to exfiltrate data, and incur arbitrary billing charges - Read-only Firebase credential compromised: Attacker can read the metrics and data accessible to the monitoring scope, a data breach risk, but not a service destruction risk #### The 2026 shift: read-only tools as a product category Until recently, purpose-built read-only monitoring tools were limited to mature enterprise platforms with established role separation (Datadog, Grafana, Splunk). Cloud provider consoles were monolithic, you got full access or nothing. 2024–2026 has seen the emergence of a new product category: purpose-built read-only companion apps for cloud providers. These tools request minimal OAuth scopes, surface the metrics that matter for on-call decisions, and by architectural constraint cannot modify production state. The Firebase ecosystem has seen several such tools emerge, with Firepulse being one of the first on Android. The pattern is also emerging in enterprise tooling: many companies now prohibit production console access on personal devices and require dedicated monitoring apps or VPN + restricted-scope credentials for on-call work. The 2026 SANS Institute DevSecOps survey found that 41% of enterprises have formal policies separating read-only monitoring access from write-access deployment credentials, up from 24% in 2023. #### OAuth scopes as the enforcement mechanism For Google Cloud and Firebase, read-only access is enforced through OAuth scopes at the credential level. The relevant scopes for Firebase monitoring are all read-only variants: - firebase.readonly , read Firebase project configuration and metadata - analytics.readonly , read Google Analytics data - monitoring.read , read Cloud Monitoring metrics - logging.read , read Cloud Logging entries - cloud-platform.read-only , read Google Cloud resources without write access A tool that requests only these scopes cannot write to Firestore, modify security rules, or trigger Cloud Functions, even if the underlying Google account has full project access. The scope restriction is enforced by Google's OAuth infrastructure, not by the tool itself. This means the security guarantee holds even if the tool's code were completely compromised. #### The on-call workflow shift in practice For a team with 3–5 developers sharing Firebase on-call responsibilities in 2026, the practical workflow change looks like this: - Normal monitoring: Check Firepulse or equivalent read-only tool on your phone during on-call. You can see crash rates, Firestore usage anomalies, and function error rates without opening the Firebase console. - Incident investigation: Read-only monitoring identifies the problem and its scope. You understand what's happening before deciding whether action is needed. - Write access when needed: If a change is required (security rule update, function rollback, configuration change), open the Firebase console with full credentials on a trusted device. The decision to use write access is deliberate, not habitual. - Post-incident review: The separation between monitoring and write-access actions creates a natural audit trail, monitoring events are separate from configuration changes. #### Limitations of the read-only console approach Read-only monitoring is not a complete security solution. Data exposure through compromised read-only credentials remains a serious risk. For projects with sensitive personal data, PII, or financial information, even read-only access to Firestore metrics and logs can expose sensitive information. The read-only approach also creates an operational friction: when something is broken and you need to fix it immediately, context-switching from a monitoring app to a full-access console adds latency to your incident response. This tradeoff is worth it for most teams but requires designing on-call runbooks that account for the two-step flow. #### Firebase's read-only scope model: a reference implementation Firebase's OAuth scope design is worth studying as a reference for any developer building monitoring tools. The granularity of read-only scopes, separate scopes for Analytics, Crashlytics, monitoring, and logging, allows tools to request exactly what they need and nothing more. A crash monitoring tool can request only firebase.readonly and monitoring.read without needing analytics.readonly . This granularity is something to emulate when building internal tooling. Rather than creating a single service account with broad project access, create purpose-specific service accounts with the minimum scopes required for each use case: one for deployment, one for monitoring, one for analytics reporting. #### Related - Post Mobile Backend Security Trends 2026 Firebase data leaks, token management, and App Check adoption in 2026. - Tool Firebase Security Rule Tester Audit 10 common Firestore and RTDB security misconfigurations. - Post Top 10 Firebase Misconfigurations 2026 The most common Firebase mistakes and how to avoid them. - App Firepulse overview Firebase read-only mobile console, all scopes are read-only by design. #### Read-only Firebase monitoring, on your phone Firepulse requests only read-only OAuth scopes. Check production metrics without granting write access to your monitoring workflow. Get it on Google Play Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . --- ## Top 10 Most Common Firebase Misconfigurations in 2026 (And How to Fix Them) **URL:** https://mobile-squad.com/apps/firepulse/firebase-misconfigurations-2026/ **Last modified:** 2026-08-12 Firepulse Firebase projects in your pocket Google Play iOS coming soon Free · subscription Security · 31 May 2026 ### Top 10 Most Common Firebase Misconfigurations in 2026 (And How to Fix Them) The configuration mistakes that hit production Firebase projects most often, and the specific fix for each one. Short answer. The ten Firebase misconfigurations that hit production most often in 2026 are led by publicly readable Firestore collections, unrestricted billing, misconfigured FCM topics and unsecured Cloud Functions. Each one below comes with the specific rule or setting that fixes it, ordered by how much damage it does when it goes wrong. By Erwan Alliaume · Firepulse · 31 May 2026 · 10 min read Firebase makes it fast to ship. That same speed means many developers skip configuration steps that aren't required for the app to function, but are critical for security, cost control, and reliability. This list covers the misconfigurations most commonly found in production Firebase projects in 2026, ranked roughly by impact. 01 / 10 CRITICAL #### Public Firestore collections ( allow read, write: if true ) The most dangerous and most common. A Firestore collection or document with allow read, write: if true in its security rules is fully accessible to anyone on the internet, no authentication required. This is a legacy pattern from Firebase's early tutorials and quickstart guides that still appears in projects created from old templates. The problem extends beyond the obvious: allow write: if true means anyone can flood your Firestore with garbage data, delete documents, or overwrite user records. Even allow read: if true exposes your entire dataset to automated scrapers. Fix Replace with allow read: if request.auth != null && request.auth.uid == userId; as a minimum. Run the Firebase Rules Playground with an unauthenticated access simulation to verify no collection returns true without auth. Also use our Security Rule Tester to audit all 10 common patterns. 02 / 10 CRITICAL #### No billing budget alerts configured Firebase on the Blaze plan charges for every API call beyond the free tier. A single bug, a Cloud Function in an infinite loop, a Firestore listener without pagination, or bot traffic hitting an unprotected HTTP function, can generate thousands of dollars in charges within hours. Google does not automatically stop billing when a budget is exceeded; the default behavior is to continue serving traffic and charging. Fix Go to Google Cloud Console → Billing → Budgets & alerts. Create a budget for your Firebase project with alerts at 50%, 90%, and 100% of your expected monthly spend. Enable programmatic notifications to a Cloud Function that can disable the worst-offending APIs. This takes 10 minutes and is the single highest-ROI Firebase configuration task. 03 / 10 HIGH #### Subcollections not independently secured Firestore security rules are not inherited by subcollections. A rule that secures /users/{uid} does not protect /users/{uid}/private/{doc} . Many developers assume parent rules cascade, they don't. Subcollections must have their own explicit match blocks. Fix Audit your Firestore data model for all subcollections. Add explicit match /users/{uid}/private/{doc} blocks with ownership checks for each one. Use Firebase Emulator locally to test access patterns across your full rules file. 04 / 10 HIGH #### Cloud Functions with no maximum instances configured By default, Cloud Functions will scale to as many instances as needed to handle traffic, up to the project quota. A traffic spike, denial-of-service attack, or runaway trigger (a function that writes to Firestore, triggering another function that writes to Firestore...) can create hundreds of concurrent instances and a billing spike before you notice. The Firestore write loop is especially common: a Cloud Function triggered on Firestore writes that itself writes to Firestore creates an infinite invocation loop. Fix Set maxInstances: 10 (or an appropriate limit for your traffic) on every Cloud Function. This caps the billing exposure from runaway scaling. For Firestore-triggered functions, always check if the write was made by your function itself and return early to prevent loops: if (event.params.triggeredByFunction) return null; 05 / 10 HIGH #### No Firebase App Check configured Without App Check , any client, a competitor's app, an automated scraper, a custom HTTP client, can call your Firebase backend as if it were your legitimate app. Billing abuse via unauthorized API calls, automated account creation, and credential stuffing are all easier without App Check protection. Fix Enable App Check in Firebase console → App Check. Use Play Integrity on Android, App Attest on iOS. Enable enforcement (not just monitoring) mode for Firestore and Cloud Functions once you've confirmed legitimate traffic is passing App Check. Takes 2–4 hours for a typical project. 06 / 10 HIGH #### Firestore indexes not optimised (missing or excessive) Firestore's auto-indexing creates composite indexes for every field in every document. For documents with large text fields, maps, or arrays, this generates index entries that inflate storage costs by 2–5× beyond the raw document size. Conversely, missing indexes on frequently-queried fields cause query failures in production. Fix Review Firebase console → Firestore → Indexes. Add single-field index exemptions for large text fields, description fields, and any field you never query on. Add composite indexes for your most common query patterns. Review the Firestore storage breakdown to identify collections where index storage exceeds document storage. 07 / 10 MEDIUM #### FCM tokens not pruned, stale token accumulation Every uninstalled app, factory reset, and app data clear leaves behind a dead FCM token in your database. Sending notifications to dead tokens doesn't cost extra, but it inflates your subscriber count by 20–40%, makes your delivery rate stats misleading, and wastes Cloud Function execution time processing UNREGISTERED errors from FCM's batch send response. Fix Store a lastSeen timestamp with every FCM token update. Run a scheduled Cloud Function monthly to delete tokens older than 90 days. Process FCM batch send responses and delete tokens that return UNREGISTERED immediately after each send. 08 / 10 MEDIUM #### Firebase Authentication email enumeration enabled By default, Firebase Authentication returns a distinct error for "email not found" vs. "wrong password", allowing an attacker to enumerate which email addresses are registered. This is a standard account privacy vulnerability known as user enumeration. Fix Enable "Email enumeration protection" in Firebase console → Authentication → Settings. This option returns the same error for unregistered email and wrong password, preventing enumeration. Available since Firebase SDK v10 (2023). Also enable brute-force protection under the same settings. 09 / 10 MEDIUM #### No Firestore read/write limits in security rules Without write frequency limits, authenticated users can generate unlimited writes, inflating your Firestore bill and potentially denying service to other users by exhausting write quotas. This is especially problematic in collaborative features, social apps with high write rates, and any feature that writes on every user action. Fix Use request.time in security rules to enforce minimum intervals between writes: allow create: if request.time > resource.data.lastWrite + duration.value(1, 's'); . For reads, consider using Cloud Functions as a proxy for expensive aggregation queries instead of direct Firestore reads from clients. 10 / 10 MEDIUM #### No monitoring or alerting on Cloud Functions errors Cloud Functions failures are silent unless you set up alerting. A function that starts returning errors due to a schema change, an upstream API failure, or a timeout will silently fail for users until someone manually checks the Firebase console, which may not happen for days in a low-traffic app. Fix Set up Cloud Monitoring alerts on Cloud Functions error rate. Go to Google Cloud Console → Monitoring → Alerting → Create policy. Alert when function error rate exceeds 1% for any function. For mobile-first monitoring, the Firepulse app shows Cloud Functions error rates across all your Firebase projects in a daily push digest. #### Using the Firebase Security Rule Tester The single highest-impact action for most Firebase projects is auditing Firestore security rules. Our interactive Firebase Security Rule Tester covers misconfigurations #1, #3, and several others on this list, it takes under 5 minutes and produces a risk grade with specific fix recommendations. #### Related - Tool Firebase Security Rule Tester Audit 10 common Firestore and RTDB security misconfigurations interactively. - Post Mobile Backend Security Trends 2026 Firebase data leaks, App Check adoption, and token security in 2026. - Tool Cloud Functions Cost Calculator Project your monthly Functions bill before billing surprises arrive. - Post Read-Only Consoles & DevOps Security Why read-only observability tools reduce production incident blast radius. #### FAQ What is the most dangerous Firebase misconfiguration? Setting `allow read, write: if true` on any Firestore collection or path in RTDB. This grants full anonymous read and write access to anyone who knows your Firebase project ID. Your project ID is visible in your app binary, so this effectively exposes your database to the public internet. How do I know if my Firebase project has a billing abuse problem? Check Firebase console → Usage and billing. Look for Firestore reads or Cloud Functions invocations significantly higher than your expected DAU activity. Enable billing alerts in Google Cloud Billing for thresholds at 50% and 100% of your expected monthly spend. A runaway Cloud Function or bot traffic hitting unprotected endpoints can generate unexpected costs within hours. Is my Firebase API key secret? The Firebase client-side API key (in your firebaseConfig object) is intentionally public, Google explicitly states it is safe to include in client code. Access is controlled by security rules, not key secrecy. However, server-side service account keys are secret and must never be included in mobile app binaries or public source code. #### Monitor Firebase errors live, on your phone Firepulse surfaces Cloud Functions errors, Crashlytics crashes, and usage anomalies across all your Firebase projects. Daily push digest, no laptop needed. Get it on Google Play Back to Firepulse Mobile Squad apps Five focused apps. Privacy-first, free to download. All apps on Google Play Personal Trainer Offline gym tracker ReplayR Instant sport replay Tennis Elbow Oracle Tennis elbow rehab Golf Elbow Oracle Golfer's elbow rehab Firepulse Firebase on mobile © Firepulse is part of Mobile Squad . Last updated 12 August 2026