How to track Firebase signups outside the Firebase console

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

The fastest way to track Firebase signups outside the console is to fire a Cloud Function on the onCreate auth trigger (or a Firestore write) and send that event to a webhook, a lightweight database, or a dashboard that ingests signals. A read-only service account can also pull aggregate data on a schedule if you don't need real-time events. Neither approach requires giving up your Firebase Console — it just stops being the only place you can see what's happening.

Most solo founders hit this wall the same way: you've got Firebase Auth wired up for one app, the console shows you a signup graph, and that's fine — until you're running three, five, or ten apps and you don't want to open ten separate tabs every morning to see who signed up overnight. The console wasn't designed for that. It's a per-project debugging tool, not a portfolio view.

Why the Firebase console isn't built for this

Firebase Console gives you real-time user counts, but it has no concept of "my other apps." There's no way to compare signup velocity across projects, no way to correlate a signup spike with a Stripe conversion, and no API endpoint that just says "give me today's signups" without you writing code first. It's also missing history beyond what the console UI chooses to show you — if you want a trend line further back than the default window, you're exporting to BigQuery and querying it yourself.

None of that is a knock on Firebase. It's an auth and backend product, not an analytics product. The gap is expected — you just need a way to get the signal out.

Option 1: Cloud Function + webhook (real-time, most flexible)

This is the cleanest option if you want signups to show up somewhere the moment they happen.

1. Write a Cloud Function that triggers on functions.auth.user().onCreate().
2. Inside the function, POST a small payload (uid, timestamp, provider, maybe email domain) to a webhook URL.
3. Whatever's on the other end of that webhook — a Slack channel, a Zapier/Make automation, or a dashboard's ingest endpoint — logs the event.

Pros: near-instant, works even if you have zero backend beyond Firebase, and you control exactly what data leaves the project (you don't have to send the email address if you don't want to).

Cons: you're writing and maintaining a small function. If it errors silently, you lose events with no easy way to notice unless you also set up error alerting on the function itself.

This is the same pattern worth using for Supabase signups if you're running a mixed backend portfolio — the trigger mechanics differ but the "fire an event, don't poll" logic is identical.

Option 2: Read-only service account (scheduled pulls)

If real-time isn't the point — you just want a daily or hourly signup count without opening the console — a service account with narrow read scopes lets an external tool query Firebase Authentication or Firestore on a schedule.

This is lower-maintenance than a Cloud Function because you're not deploying code, but it's not instant. You're trading immediacy for simplicity. For most solo founders checking metrics once a day or during a weekly portfolio review, that trade is fine — you don't need to know about a signup within seconds, you need to know the trend held or broke by the time you check in.

Scope the service account tightly: read access to auth user counts or a specific Firestore collection, nothing broader. If a tool asks for more than that to show you signup counts, that's a reason to ask why.

Option 3: BigQuery export (best for deep analysis, worst for simplicity)

Firebase can stream Auth and Analytics events into BigQuery. Once there, you can query signup counts, cohort them by day, join them against other tables, whatever you want. This is the right call if you're already comfortable in SQL and want to build custom cohort or retention analysis.

It's overkill if all you want is "how many people signed up yesterday across my five apps." You'd be maintaining a BigQuery dataset and writing queries just to answer a question a webhook could answer in one line of a Slack message.

Signals vs. metrics: know which one you're actually building

Signup counts are what SoleOS calls a signal — an event that tells you something happened, as opposed to a metric like MRR or churn rate that gets computed from a stream of financial data. Signals are cheaper to pipe out (you're just forwarding events) but harder to make actionable on their own. A signup spike means nothing until you know whether those signups converted, which is why most founders eventually want signup signals sitting next to revenue metrics from Stripe or RevenueCat, not in a separate silo. See Stripe and RevenueCat tracked together for the metrics side of that pairing.

Where SoleOS fits (and where it doesn't)

Disclosure: SoleOS is our own product, so take the following as an interested party's description, not a neutral review.

SoleOS connects to Firebase as a signals source, using a service account or webhook, read-only, and shows signup activity alongside metrics from your other connectors — Stripe, RevenueCat, GA4, App Store Connect, Play Console — so a signup spike on one app can sit next to the revenue chart of another. That's genuinely useful if you're running several Firebase-backed apps and don't want to reason across five console tabs plus a spreadsheet.

It is not useful if you have one Firebase app and just want a signup counter — the Cloud Function + Slack webhook approach above is faster to set up and free. SoleOS earns its keep at the point where you're maintaining enough separate projects that "checking each one individually" is itself the cost. Full scope and revocation details are in what SoleOS connects to, and if you want to see the shape of a populated dashboard before connecting anything, the live demo uses sample data, not your real accounts.

FAQ

Frequently asked questions

Does Firebase have a built-in API for signup counts?

Firebase Authentication doesn't expose a simple REST endpoint for aggregate signup counts. The Admin SDK lets you list users and their creation timestamps, which you can count yourself, but there's no "give me today's total" call. That's exactly why the Cloud Function or service account patterns above exist — they build the aggregation you'd otherwise do by hand.

Will a webhook approach cost me anything on the Firebase side?

Cloud Functions run on a pay-per-invocation pricing model, and auth trigger functions typically fire rarely enough (once per signup) that cost is negligible for most solo apps. Check your own invocation volume in the Firebase console's usage tab before assuming — if you have an app with unusually high signup churn or bot traffic, that's worth confirming directly rather than guessing.

Can I track Firebase signups without writing any code?

Yes, if you use a tool that connects via service account and handles the polling for you — you configure scopes once and never touch a Cloud Function. The tradeoff is you get scheduled pulls, not instant events. If you want instant, some no-code automation platforms (Zapier, Make) offer Firebase triggers that skip the custom function step, though they still require you to wire up the webhook destination.

Is it safe to give a third-party tool access to my Firebase project?

It's safe if the access is scoped narrowly — read-only, limited to the specific data you want (auth events, not full database read/write) — and revocable from your own Google Cloud IAM console at any time. Before connecting anything, check exactly what scope it's requesting; a tool that needs write access or full project admin to show you a signup count is asking for more than the job requires. See the security overview for how SoleOS specifically scopes and documents each connector.

How do I compare signup trends across multiple Firebase apps?

You need each app's signup signal landing in one place with a consistent timestamp and app label, then you're just looking at parallel trend lines or a shared table. Whether that "one place" is a spreadsheet you update manually, a BigQuery dataset, or a dashboard built for multi-product tracking depends on how many apps you're running and how often you check — see SoleOS vs a spreadsheet for an honest breakdown of when each makes sense.