How to build an Event Logging System with Firebase and Google Cloud Firestore

Asynchronous systems need to be able to notify their users about changes — which can be persisted as events and distributed through webhooks.

Don’t just wait until the events bite. (Photo by James Wheeler)

The Problem

Naturally in an asynchronous system, we can only provide the user with direct feedback for direct requests (e.g. when a request resource is invalid). To check if some event has occurred in the background, the user would need to query the API every time.

A Solution

We can come up with a solution by looking at the commonalities of the two types of information we generate. By abstracting the underlying system it becomes obvious that both are „events“ — something that has occurred in our system, be it an error or some finished task. Let’s model the architecture around the concept of events.

Step 1: Plan how to structure the data

Create a collection events within Firestore. Each of the future documents should have the following fields:

  • name: a string used for identification purposes, e.g. „user.processed“
  • payload: a map used to store arbitrary data of the event
  • isCritical: a boolean to indicate that this is an event that is not supposed to happen (also called „Error“)
  • createdAt: a timestamp used for sorting and display

Step 2: Store the events

Whenever an asynchronous action in a Cloud Function finishes, let the Function create an event in the events collection.

Step 3: Display the events

In your UI you can display and access the events collection like usual. You might want to include a switch to filter for only critical events (based on the isCritical flag). If you are using the Firebase libraries this will also give you realtime updates when new events are created. This can greatly enhance the developer experience because it allows to „watch“ how your app is working in the background.

Step 4: Fire webhooks for new events

Thanks to the fact that you have a concrete list of event types now, you can just pipe them through a webhook system. This way the user can decide for which events he wants to set up a webhook and if he wants to listen for error events.

Step 5: Notify the user of critical events

In the same Cloud Function that fires the webhook, you can check if the event has the isCritical flag set. If it does, you might want to notify the consumer of the issue by email or even push notification. Through the API of a service like Sendgrid or Mailgun, one can send an email template filled with the relevant event details.


And that’s it. By abstracting the initial problem one is able to build a robust system that plays on the strengths of the Firebase ecosystem. We are now able to persist different types of events and notify the user about them through webhooks or the UI. Let me know if you have any questions or feedback about the proposed solution.



Tutorials, deep-dives, and random musings from Firebase developers all around the world. Views expressed are those of the authors and don’t necessarily reflect those of Firebase or its parent companies.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store