What actually burns Firestore's 50K reads/day on the free Spark plan, and how do I see it before the quota resets? Quota hit

Listeners, almost certainly.

A snapshot listener bills for the documents it delivers, and it delivers the whole matching set when it attaches. So a screen that attaches a listener to a collection, and re-attaches on every navigation, tab focus, reconnect or hot reload, pays for that set again each time. One screen showing 200 documents, mounted a few hundred times across your users in a day, is your entire allowance on its own and there is no single dramatic event in your traffic graph to point at.

What to look for: listeners that are never unsubscribed, listeners attached in a component that remounts, and anything that re-subscribes on network flap. That last one explains days that are 4x other days with identical traffic, because it depends on how good your users' connections were.

Second big one: reading a collection in order to count it. If any screen shows "you have 47 of these", and it gets that number by pulling 47 documents, you are paying 47 reads for one integer that the user glances at.

Two fixes, in order of effort. Use the count aggregation rather than fetching documents. Or, if the counter is on a screen everyone opens, denormalise it into a single document you update on write. Writes are 20K/day, and one write per change is much cheaper than N reads per view.

This one is worth auditing specifically because it does not feel like a read-heavy operation while you are writing it.

Answering (3): your own development traffic counts. Same project, same daily quota. Every hot reload that re-runs a query, every time you open the console and browse a collection, every integration test run.

Use the local emulator suite for day to day work, and a separate project for staging so it has its own quota. For a lot of small apps this alone is the difference between comfortably inside the limit and running out at 3pm, and it costs nothing to change.

On (2): you will never get attribution from the daily total, so instrument the client.

Wrap the read helpers in one function that takes a label. Increment a counter per label with the number of documents returned. Ship the counters somewhere once a session, or just log them in dev and look. Twenty minutes of work and it usually names the guilty screen on the first day, because these things are never evenly spread, it is always one query doing 80% of it.

I resisted this for a week and did guesswork rewrites instead, all of which were wrong.

Worth saying out loud once: sometimes the answer is that the free tier is the wrong size for your app and the cheapest available fix is to stop engineering for zero.

Do the instrumentation first, because a genuinely broken listener will follow you onto the paid plan and cost real money there. But if after that you are simply an app that legitimately needs more than 50K reads a day, weeks of your time to stay at $0 is not a good trade. Decide it deliberately rather than drifting into it.

Are you sure you are reading the limit right? I was under the impression the 50K is per user per day, in which case a few hundred users would be nowhere near it and you would be looking for one abusive client rather than a structural problem.