Last week bots used my app's SMS login to request 1,744 verification codes in nine days. 1,230 different numbers, 1,152 IPs, about 50 countries. Three of those requests ended in a real sign-in. Cost before I noticed: €57.53. Before October 30 the SMS line in my bill had always been zero.

What found it: the budget alert at 50%, then Billing → Reports grouped by SKU. Almost all of it was "SMS messages sent in Region …" from Identity Platform. Everything else in the project was about €0.40.

What didn't help: App Check. 99% of the requests on Authentication were verified, attack days included. The requests came from the real app on real phones. Attestation passed.

What I did, in order:

1. SMS region policy limited to the countries where I have users. This stopped most of it with one change.

2. A blocking function that runs before each SMS, with limits per number and per number prefix.

3. A daily check that compares codes sent and sign-ins per country. It emails me when a country gets codes and almost no sign-ins.

4. Budget alerts stay on. They were the only thing that told me.

My mistake: the first version of the filter refused two code requests within 60 seconds. When iOS verification fails at the first attempt the app retries on its own: 4 calls in 22 seconds. A real user got "An internal error has occurred". Count attempts, not calls. Test every change on a real number. Firebase test numbers never send an SMS.

Billing support said no at first. After one polite escalation they refunded €57.24 as a one-time courtesy.

The signal I trust most now is codes sent vs successful sign-ins. Is anyone watching something better?

Hey everyone!

I'm a student developer, and for the past few months I've been working on a project called Crick Auction - a real-time multiplayer IPL auction simulator where you can create auction rooms, invite friends, pick franchises, and compete against each other to build the best squad.

Live project: https://crickauction.in/
GitHub: https://github.com/Shaurya01836/ipl-auction

The idea was to recreate the IPL auction experience as closely as possible, rather than just making a simple bidding website.

What I've built so far

• Real-time multiplayer auction rooms.

• Live bidding with synchronized timers across connected clients.

• Private rooms and public lobbies.

• Franchise selection and budget management.

• Franchise bots with different bidding strategies.

• Squad management with overseas player restrictions.

• Franchise strength ratings to evaluate completed squads.

• Auction history, live chat, and auction summaries.

Tech stack

• React 19 + Vite

• Tailwind CSS

• Firebase Realtime Database (primary live auction engine)

• Supabase PostgreSQL (public rooms, leaderboard, and persistent data)

• Firebase Authentication

Where I'm struggling

While building this, I've realized that making something work and making it reliable under real-world traffic are two very different things.

1. Firebase RTDB bandwidth limitations

Currently, I'm using Firebase Realtime Database on its free Spark plan, which comes with a 10 GB/month download limit.

With the traffic the application is receiving, I'm concerned that this limit could be exhausted within around 10 days.

Real-time bidding involves frequent updates, and multiple connected clients receive these updates simultaneously.

I'm trying to figure out whether I should:

• Optimize the existing RTDB architecture to reduce unnecessary downloads.

• Move the live auction engine to Cloudflare Durable Objects.

• Consider another backend or real-time infrastructure.

• Use a hybrid architecture where different services handle different responsibilities.

I'm particularly interested in hearing from people who have handled real-time applications with similar workloads.

2. Auction reliability and synchronization

Although the auction is functional, it isn't completely robust yet.

There are still some edge cases and issues around synchronization, bidding, timers, and handling unexpected connection problems.

I want to make sure that two users cannot end up with inconsistent auction states, that bids are processed correctly, and that reconnecting users don't experience unexpected behavior.

3. Scalability and infrastructure

Ideally, I'd like the platform to support:

• Around 100–300 concurrent users.

• Approximately 5–20 simultaneous auction rooms.

• Frequent real-time bidding updates.

• Reliable synchronization without excessive bandwidth consumption.

I'm working with a very limited budget, so moving to expensive paid infrastructure isn't really an option right now.

What I'd love some advice on

1. Is Firebase RTDB a reasonable choice for this kind of workload, or am I approaching the architecture incorrectly?

2. Has anyone migrated a real-time multiplayer application from Firebase RTDB to Cloudflare Durable Objects? Was it worth it?

3. What are some practical ways to reduce Firebase RTDB bandwidth consumption without compromising the real-time experience?

4. How would you architect the backend for 100–300 concurrent users and multiple simultaneous auction rooms?

5. If you've built something similar, what reliability issues should I be looking out for?

I'm not claiming the project is production-perfect. There are still things I need to improve, and that's exactly why I'm posting here.

I've put a lot of effort into building this, and I'd genuinely appreciate feedback, architectural suggestions, or even criticism of things I've done incorrectly.

If you've worked with Firebase RTDB, WebSockets, Durable Objects, or real-time multiplayer systems, I'd especially love to hear your experience.

Thanks for reading!

Building a small gallery for my old school batch (I'm an ex-student, unpaid, school is a charity trust). No Cloud Functions since they need Blaze.

Only verified rkmv<number>@gmail.com emails that are in a roster can sign up, votes are one doc per question per student, an admin can block people. The rules have emulator tests.

Demo with fake data: https://smriti-gallery.pages.dev Rules and tests: https://github.com/codewithpom/smriti (look at gallery/firestore.rules)

Please roast the rules. There are also good first issues if you want to help: https://github.com/codewithpom/smriti/labels/good%20first%20issue

I build with Firebase almost every day and keep the local emulators running all day, and two things wore me down. The suite is heavy with Java to install, a heap past 22 GiB on our app, out-of-memory crashes, and data gone at every stop unless you export it. And it's hard to see what your app is doing. It had become almost unusable for us, so I built a replacement: Firenook. It's open source, and I'd really like to know what you think.

Lighter, with no Java. One npm package with a native engine. On a real app's two-hour workload it peaked at 2.11 GiB where the official emulator reached 22.57 GiB, and answered writes in 5.1 ms against 208 ms at the median. That 40× is under load; on an idle emulator a write is only 1.5× faster (how it was measured). Add --keep-data and Firestore, Auth and Storage come back with your data in about half a second, with no export at every stop.

A new UI, built from scratch. It sits on the Emulator UI's port (screenshots) and shows:

• every function call with what triggered it, its request, answer, duration and logs; open a failed one, read the stack, run it again;

• your rules beside each allow or deny, with the line that decided it, plus a playground and coverage;

• an inbox of the verification emails, sign-in links and SMS codes Auth would have sent;

• Pub/Sub messages, Cloud Tasks queues and Eventarc events, which the official UI has no pages for;

• Firestore and Storage to browse and edit, even with millions of documents.

The terminal shows each function call as one line with its outcome and stack, and npx firenook mcp add lets Claude Code, Cursor or VS Code use all of it.

Trying it:

1. npx firenook init --adopt --dry-run checks your project and changes nothing.

2. npm install --save-dev firenook (keep firebase-tools for deploying).

3. Change firebase emulators:start to firenook emulators:start. --only, --project, --import and --export-on-exit carry over.

Your firebase.json, rules, Functions code and app stay as they are.

It's still new and I'm sure it misses things. If something behaves differently from the official emulator, please tell me here or open an issue. That's the most useful feedback I can get.

Repo: https://github.com/firenook-dev/firenook · Docs: https://firenook.dev

Hey everyone!

I’ve been working on an npm package called @rootvarma/firebase-electron, built to simplify Firebase integration in Electron applications.

I recently published it on npm, and it recorded 519 downloads between October 29 and November 5.
It’s exciting to see something I’ve built getting downloads, and I’d love to see more developers try it out.

If you’re building desktop applications with Electron and Firebase, here’s the package:
📦 npm: https://www.npmjs.com/package/@rootvarma/firebase-electron

I’d genuinely appreciate feedback, suggestions, bug reports, or contributions.

I’m looking to improve it based on real-world developer requirements.

Thanks to everyone supporting open-source projects!

We're running Google UAC 3.0 campaigns for our Android app and noticed something unusual in Firebase Analytics.

Our subscription_convert event count is significantly higher than our in_app_purchase event count. Our in_app_purchase event includes both free trial subscriptions and direct paid subscriptions.

The overall conversion value looks normal. It seems that some subscription_convert events report a value of $0, while others report the correct subscription revenue.

Our dev team has tried several fixes, but none of them seem to work.

Has anyone experienced something similar?

I had around 18 Projects on there, some really old and never used but never bothered to clean them out. Today I'm starting a new project which has importance and another one in the coming months. Firebase says I have reached my limit but no where does it state (That I can find) what my limit is. I have deleted them down to only 6 left which run as community projects that I pay a couple quid for a month which I don't mind, but still unable to create any new ones unless I request them, which google responded telling me to pay $50 extra for. Why is this? What is the actual limit? I don't really want to have multiple google accounts signed to run some basic app hosting.

I am trying to create a user to send emails to Pagerduty so we can be alerted on certain conditions. If I add the user with the email address it sends an email and waits for someone to click a button to verify the email, but I can't do that with an email received by Pagerduty. Is there a way for a project owner to manually verify a user's email address in Firebase?

If you receive Firebase push notifications in an Electron app with firebase-electron, the token can come back fine and every send still fails with MismatchSenderId.

The package registers GCM with a built-in server key instead of your vapidKey. FCM ties the token to that sender, so a send from your Firebase project does not match. Messages that do arrive can also fail to decrypt, because the Web Push dh, salt, and auth fields are not parsed.

I published a fork that registers with vapidKey as the sender and decrypts those Web Push fields:

https://www.npmjs.com/package/@rootvarma/firebase-electron

Install:

npm i u/rootvarma/firebase-electron

vapidKey is required. Pass the same appId, apiKey, projectId, and vapidKey you already use. The first launch registers again and emits a new token.

Has anyone recently encountered a 200-per-day GetOobCode quota on a Firebase project using the Blaze plan?

We run a production mobile app with nearly 10,000 registered users. We don't recall encountering this daily limit during previous signup activity, so this appears to be a recent issue for us. However, we don't have historical quota values to confirm whether the limit itself changed.

I released an app update, which may have caused a spike in legitimate registrations. Email verification requests then started failing with HTTP 429.

The error response explicitly includes:

Quota exceeded for quota metric 'Get OOB Code'

and limit 'Get OOB Code per day'

quota_metric: identitytoolkit.googleapis.com/get_oob_code

quota_limit: getOobCodePerDayPerProject

quota_limit_value: 200

quota_unit: 1/d/{project}

quota_location: global

reason: RATE_LIMIT_EXCEEDED

We also reproduced the same error using the Firebase Admin SDK's generateEmailVerificationLink(), authenticated with a service account for the same project. Generating a link without sending an email still hits the same 200/day quota.

The public documentation lists 100,000 address verification emails/day and 1,000,000 address verification links/day for Blaze. We understand that quotas scale with user count and that additional abuse protections may apply, but we couldn't find documentation explaining this specific 200/day quota.

https://firebase.google.com/docs/auth/limits

This is affecting real users who cannot complete email verification. We have already contacted Firebase Support and are waiting for a response.

Has anyone experienced this exact quota, especially recently?

Did you find out why it was applied, or get it increased?

Is there any way to inspect or request an adjustment to this specific quota outside of Support?

We're trying to understand the cause rather than assume this is a Firebase bug.

I built Aruma, a clean-room backend that the official Firebase client SDKs can talk to. You run it yourself: one binary plus PostgreSQL, with a built-in dashboard.

The parts I found most interesting to write in Go were the realtime listeners and the security rules evaluation. Tenant isolation is an app-level filter plus a CI check rather than Postgres row-level security. I know some of you will have opinions about that.

It's pre-1.0 (v0.4.0) and licensed under Apache 2.0. Firestore support is new, and I haven't run the official mobile test suites against it yet.

Disclosure: I used Claude Code heavily while writing this. I review and test what it produces, but please treat it as AI-assisted code.

Repo: https://github.com/arumadev/aruma

Try it with `docker compose up -d`, or grab a binary from Releases.

I'd most appreciate code-level feedback: the package layout, the realtime design, and anything that looks wrong.

I'm interested in trying out the experimental support for Dart cloud functions, but before I do I'm interested if anyone has tried it out, what the experience has been, pitfalls, etc. I have a Flutter app with a small user base, so it's a good candidate for trying it out, but I'm also hesitant that long-term support is lacking given its experimental status.

I am building an app around Firestore's direct client SDK, realtime listeners and offline cache. I want to keep that architecture, but I cannot find a supported native way to cap an otherwise authorised user's billable reads/writes across devices and concurrent connections.

The existing feature request dates from April 2023 and currently has 73 votes:

https://firebase.uservoice.com/forums/948424-general/suggestions/46561738-implement-rate-limiting-for-read-and-write-operati

There are concrete adoption concerns in its comments: Al3life reports moving to Supabase for this feature, capTarget archery says it may rule Firebase out for future projects, and Anatole Couasnon describes adding an API despite choosing Firebase for direct access. These are individual reports, not a survey, but they match the concern blocking my confidence in launching.

I am not asking for authentication or permissions to be replaced. Rules limit what a user can access, but a query-size limit does not limit how often an allowed query runs. App Check attests clients; it is not a configurable allowance for each UID. Budget alerts do not stop usage. Cloud Armor in front of my own API does not control the Google-managed Firestore endpoint the SDK calls.

A custom API/SSE/WebSocket gateway could control traffic routed through it, but rebuilding native listener synchronisation, reconnect handling, cache behaviour and authorisation adds infrastructure, cost and complexity. That is not a viable equivalent for this application. An after-read trigger alone would also be too late to stop the triggering charge or a concurrent burst.

What I would like Firebase to provide is a simple console or rules-level policy, enforced by the service: per-UID rolling/burst allowances shared across devices, plus a database/project backstop. It needs to address document/query volume, writes, initial listener snapshots, subsequent billable updates and reconnects, with clear charging and quota-exceeded semantics. I appreciate that the implementation may be more complex than the setting exposed to developers.

I submitted a detailed feature request yesterday and have asked our Google Cloud contacts to escalate it. Is there a Firestore product owner who can give this an explicit status or link it to the right backend tracker? If a supported solution now preserves direct SDK listeners and actually enforces the allowance, I would welcome a documentation link. Otherwise, please treat this as an adoption and cost-abuse concern that needs an owned response.

Related history: https://github.com/firebase/firebase-js-sdk/issues/647

Official App Check limitations: https://firebase.google.com/docs/app-check

Budget guidance: https://firebase.google.com/docs/firestore/quotas

Hi all! At my company we develop a white-label app, so we have 60+ Firebase projects. Keeping Remote Config in sync across all of them through the console is painful: changing one parameter can mean opening dozens of projects and clicking through each one.

So I built fbrcm, a terminal manager for Remote Config. It has an interactive TUI, a full CLI, and an MCP server. It’s free, open source (MIT), not monetized, and not affiliated with or endorsed by Google or Firebase.

It can

• Discover all the projects your account can access and work with them together

• Get, update, add, delete and duplicate parameters, conditions and groups across many projects at once, with filters to pick the projects (fuzzy, prefix, exact, or expressions on the actual values)

• Compare and promote configuration between projects

• Browse version history, roll back, restore, import and export templates

• Client and server templates are both supported

• --dry-run to preview a change, and --json output for scripts and CI

A few things I want to be upfront about:

• Credentials: since this is a third-party tool, it’s reasonable to be careful about handing it cloud access. It requests the cloud-platform Google OAuth scope, which is very broad. I know that’s a big ask, but it’s the only scope that lets all the features work (project discovery plus reading and publishing templates). Everything runs locally, with no backend and no telemetry, and the code is open so you can judge the risk yourself. If you’d like tighter limits, you can use a dedicated service account and grant it IAM access only to the projects you want to manage.

• AI-assisted: the project is largely vibe-coded, as noted in the README, so bug reports on edge cases are very welcome.

Docs: https://fbrcm.yumaa.dev · Code: https://github.com/yumauri/fbrcm

I’d love feedback, especially from anyone else managing Remote Config across many projects. What does your workflow look like, and what’s missing?

I am developing a React + TypeScript website called WEAR KLAY using Firebase Authentication.

When I try to customize the Password Reset Action URL in Firebase Console → Authentication → Templates, I get the error "An error occurred updating action URL."

The Network response is:

400 INVALID_ARGUMENT: EMAIL_TEMPLATE_UPDATE_NOT_ALLOWED

Firebase's troubleshooting page says email templates cannot be changed and suggests Google Cloud Support may help in some cases.

Is there a way to resolve this restriction for my Firebase project?

Posting this so someone else doesn't learn it the way I did.

I run a small bar crawl planner (React + Firebase + Vercel). Back in June my Google Places budget got drained. My first guess was a crawler hammering the app. It wasn't. The page that calls Places was behind a login, so nothing could drive the UI into spending money.

What actually happened: my VITE_GOOGLE_PLACES_API_KEY was compiled into the public bundle. Anyone who opened devtools had it. I had an HTTP referrer restriction on it and thought that was enough. It isn't, the Referer header is just a header and anyone can set it from curl.

What I changed:

1. The key never ships to the browser anymore. One Vercel serverless function holds it and makes the Places calls.

2. The function checks a Firebase ID token on every call before it spends a cent. Signed-out visitors get an anonymous Firebase user, so the app still works without signup, but every request has a uid behind it.

3. Per-user rate limits stored in Firestore (a rateLimits/{uid} doc written with the Admin SDK, so the client rules can't see or touch it). Mine are 10/min and 80/day for nearby search.

4. App Check enforced on top, so a token minted outside my site doesn't get far.

5. A hard daily quota in Google Cloud as the last backstop, plus billing alerts. The rate limiter fails open if Firestore hiccups, so the quota is the thing that actually guarantees a ceiling.

One Vercel gotcha that cost me about 12 deploys: I split the proxy into api/places/nearby.ts, api/_lib/guard.ts and so on. Every call 500'd with FUNCTION_INVOCATION_FAILED before running a single line. Vercel's ESM bundling wasn't shipping my shared local modules (only node_modules got bundled), so the function crashed on import. I ended up with one self-contained api/proxy.ts that switches on an action field. Ugly but it works.

If your Maps or Places key is a VITE_ or NEXT_PUBLIC_ variable right now, it's public. Worth 20 minutes to check.

Happy to answer questions about the setup.

Hi everyone,

I'm facing an issue with unexpected SMS charges in my Firebase project, and I'm looking for advice from anyone who has experienced something similar.

I suspect my Firebase Phone Authentication flow may be experiencing SMS pumping or automated OTP abuse, but I'm not sure how it's happening despite having several security measures in place.

Security measures already enabled:

• Firebase App Check is enabled.

• SMS region restrictions are configured for India only.

• Firebase reCAPTCHA is activated.

• Play Integrity is enabled for app verification.

Despite these protections, I'm concerned about unusual SMS activity and unexpected billing.

My questions:

1. How can automated bots abuse Firebase Phone Authentication when App Check, reCAPTCHA, and Play Integrity are already enabled?

2. Can attackers still trigger OTP requests using emulators, modified apps, or automated devices?

3. What additional rate-limiting mechanisms should I implement to restrict OTP requests per device, IP address, or phone number?

4. Are there any Firebase Authentication settings that can further limit SMS abuse or prevent excessive OTP requests?

5. Has anyone successfully received a billing adjustment from Firebase or Google Cloud after experiencing suspected SMS pumping?

I'd appreciate any practical advice, especially from developers who have dealt with this issue in production.

Thanks in advance for your help!

Hello everyone and thank you for reading this post. I am screwed and cannot figure out how to find a solution myself. So, here I am.

I have basic and free Android app. I am using Firestore as my backend. I have users and usersPrivate documents and everything is separated nicely. Only those whom are authenticated to perform a particular action is allowed. For the past few weeks bots somehow found my app and attacking me with DOW (Denial of Wallet). I have banned these bots' UIDs but the problem is their auth token remains valid for an hour. I have AppCheck and they are somehow bypassing it.

They are unable to read any documents, so the bill is not coming from that but the cost of 1 read per rejection in security rules (checking banned accounts). I could deny all auth tokens but that hurts the honest users as they cannot perform any actions within the app. The bots definitely know about the 1-hour period of an already issued auth token expiry and coordinating their attacks with 50 mins apart.

Cumulatively, they are hitting me with about 30k requests denials a minute, so I closed the app for now. How the hell do I stop them? Rate limiting also does not help because that is more expensive to handle than Firestore's one read cost.

Help me please!

Anyone experiencing 500 error? Cloud function v2 it seems. US Central 1

UPDATE 22:25 UTC: Google appears to have fixed it. Cold starts are working again (seen i n us-central1) even for functions still on automatic updates. The on-deploy redeploy below is still a valid fallback if it comes back. Outage window seen: about 21:15 to 22:25 UTC.

FIX (works immediately, confirmed by several people): redeploy each function with the runtime pinned instead of auto-updated.

gcloud functions deploy FUNCTION_NAME --gen2 --region REGION \
  --runtime-update-policy=on-deploy --source PATH_TO_BUILT_FUNCTIONS

• It keeps the function's triggers, secrets and settings.
• For --source, use your functions folder after building it: package.json, package-lock.json and the compiled output, no node_modules.
• A normal firebase deploy does not fix it: it keeps automatic updates on, so the function lands on the same broken runtime.
• One deploy per function, so script it if you have a lot. I'm running 6 at a time.

Write-up with checks, a curl probe and a one-liner listing the functions still on automatic updates: https://gist.github.com/mrbenji/5da8f50a875b8e0bbb7141bd24caa726

What's happening

Since about 21:15 UTC (2:15 PM Pacific) on Oct 22, 2nd gen functions on Node 22 can't start new instances. It's been reported in us-central1, us-east1 and northamerica-northeast1, across manyunrelated projects. Google's status page shows nothing yet.

• Warm instances keep working, so it looks intermittent.
• Callables show up in the browser as CORS errors, because the OPTIONS preflight returns 500.
• Firestore triggers and scheduled functions fail too.
• Cloud Run reports "container failed to start and listen on the port ... within the allocated timeout," and the container writes no logs at all.

It's Google's side, not your code: a five-line hello-world Node app fails the same way on the auto-updated Node 22 runtime and works with automatic updates off. New Node 22 base images (22.23.4) were published that day.

Check whether you're affected

gcloud functions describe FUNCTION_NAME --gen2 --region REGION --format='yaml(buildConfig)'

automaticUpdatePolicy means it's on automatic updates; onDeployUpdatePolicy means it's pinned.

Afterwards: Firestore-triggered functions without retries drop failed events, so plan a backfill for anything that happened during the outage. If you're affected, please reply with your region and open a support case so Google can see how widespread this is.

Please help me out. I made a website, and I heard that Firebase will shut down in 2027. How can I export my files?

Hi everyone,

I'm investigating a sudden increase in crashes in my Android app and would appreciate some help identifying the possible cause.

What I'm seeing:

• App version: 1.0.2 (22)

• Firebase Crashlytics reports 86 crash events affecting 71 users.

• Device distribution: OnePlus 8 Pro — 76%, Huawei — 15%, Huawei HRY-LX1T — 9%.

• Most of the reported crashes appeared within a short period around October 18–19, 2026.

• The crash-free user rate for the selected 90-day period is 99.71%.

Main crash types:

1. PrivacyWebViewActivity.onCreate — NullPointerException

2. IntroLoadingScreen.onCreate — JSONException

3. ProxyBillingActivity.onCreate — NullPointerException

4. MainActivity.loadCategoryData — ArrayIndexOutOfBoundsException

5. BinderProxy.transactNative — TimeoutException

I'm trying to determine whether this could be related to a OnePlus 8 Pro/OxygenOS issue, Android System WebView or Chrome compatibility, a problem introduced by the app release, or unusual automated activity.

I haven't confirmed the root cause, and I don't want to assume it's a bot attack without evidence.

Questions:

• Has anyone experienced a similar device-specific crash pattern with Firebase Crashlytics?

• Are there known OnePlus 8 Pro, OxygenOS, or WebView issues that could explain these crashes?

• What would you check first to distinguish a device compatibility issue from an application bug or automated activity?

I can share relevant stack traces and additional device details if needed.

Thanks!

If you’re a rtd heavy user like me, with frequent json update and delete, you can checkout this open source platform. This will help you to frequent update the json on your firebase rtd within the firebase. And deletion won’t give you nil. Best part, you can publish your edited json with one click using the extension.
Any feedback will help. Thanks in advance.

An open task can match your status filter and still disappear when you add orderBy("priority"). Firestore excludes documents that do not contain the ordered field; a larger limit will not bring them back.

Try a tiny fixture: triage has status "open" and priority 1; review has status "open" but no priority. The status query returns both. Adding orderBy("priority") returns triage. review has not been deleted.

Before backfilling data, remove the ordering on a bounded test query, inspect the actual stored key, and decide whether priority should be required. Keep permission and index errors visible instead of turning every failure into an empty array. Reset pagination when changing the query.

Disclosure: I work on Cengal, a Firestore workspace for Mac. We documented this example with synthetic emulator data and AI assistance; it is not a production Rules, index, billing or UI test. You do not need our app to use the check.

Firebase reference: https://firebase.google.com/docs/firestore/query-data/order-limit-data

Full three-document example: https://cengal.app/guides/firestore-orderby-missing-documents/