Firebase Alerts Routing Shift from Console Email Fan‑out to Cloud Functions 2nd Gen firebasealerts Triggers

Question

Teams need to decide how to handle Firebase Alerts to keep notification volume manageable without missing important signals. The default console configuration sends every alert email to all project members, offering no built‑in way to scope messages by alert type or individual recipient. An alternative is to intercept alerts with Cloud Functions 2nd gen firebasealerts triggers, filter them in code, and forward only high‑severity events to the appropriate channels or users.

This approach depends on the availability of firebasealerts event triggers for the chosen runtime and region, and introduces additional function invocations that could recreate noise or add cost if not carefully filtered. Before committing to either path, teams must confirm what routing options the Firebase console currently provides and verify which alert categories are supported by the trigger in their target environment.

What scoping options does the Firebase console provide for alert emails by alert type and project member? Does the firebasealerts trigger support all alert categories (Crashlytics, Performance, App Distribution, billing) in the selected runtime and region? How does the expected cost of filtered forwarding compare to accepting the default fan‑out in terms of function invocations and risk of missed alerts?

Tasadduq Burney · Answer

The Firebase console does not provide granular scoping for alert emails. There is no built-in routing matrix to send specific alert types to specific project members; notifications are generally delivered as a broad fan-out to all members with appropriate project roles. While individual users can adjust some notification settings, the console cannot be configured to route "Crashlytics Fatals" to one team and "Performance Regressions" to another.

Trigger Support and Limitations
The firebasealerts trigger for Cloud Functions 2nd Gen (powered by Eventarc) does not support all alert categories. Its coverage is primarily focused on Crashlytics and App Distribution. Specifically:

Supported: Crashlytics events such as onNewFatalIssuePublished, onNewNonfatalIssuePublished, onRegressionAlertPublished, and onVelocityAlertPublished.
  Unsupported: Billing alerts. Billing budget notifications are handled via Cloud Billing budget Pub/Sub topics and require a separate subscriber function; they do not flow through the firebasealerts trigger.

Availability of these triggers depends on the Eventarc region and the specific Firebase Functions SDK version used in your runtime (Node.js or Python). You must verify the event types available in your SDK version before implementation.

Cost and Risk Analysis
Comparing the two routing methods involves a trade-off between operational noise and infrastructure overhead:

Metric
      Console Fan-out
      Filtered Trigger Forwarding

Direct Cost
      Zero
      Eventarc + Function invocation fees

Signal-to-Noise
      Low (High noise)
      High (Customizable filtering)

Reliability Risk
      Low (Managed by Google)
      Moderate (Filter logic errors, function timeouts)

The financial cost of function invocations is typically negligible for standard alert volumes. However, the primary risk is missed alerts due to overly aggressive filtering or function failures. To mitigate this, it is recommended to keep the console fan-out enabled as a fallback during the initial rollout of the trigger-based system.

Verification Steps

Check your runtime's SDK reference for the exact firebasealerts event types supported.
  Deploy a test function to a supported region and trigger a Crashlytics fatal issue to verify the payload contains the necessary metadata for your filters.
  Configure a separate Pub/Sub trigger for Cloud Billing budgets to ensure billing alerts are not lost.

Missing Detail: Please specify your target deployment region and runtime version, as Eventarc trigger availability varies by location.

Firebase Alerts Routing Shift from Console Email Fan‑out to Cloud Functions 2nd Gen firebasealerts Triggers

1 answer

Trigger Support and Limitations

Cost and Risk Analysis

Verification Steps

Your perspective belongs here.

0 question comments

Metric	Console Fan-out	Filtered Trigger Forwarding
Direct Cost	Zero	Eventarc + Function invocation fees
Signal-to-Noise	Low (High noise)	High (Customizable filtering)
Reliability Risk	Low (Managed by Google)	Moderate (Filter logic errors, function timeouts)