How to connect Firebase to Slack for backend events with no other home

Firebase covers a lot of ground — a database, authentication, crash reporting, messaging, hosting — and the events worth surfacing come from different parts of it with nothing joining them. A crash spike, a suspicious authentication pattern, and a document written in an impossible state are all things somebody should know about, and none of them notifies anybody by default.

That is the gap. Not a general event stream, but a handful of signals from a platform whose parts do not talk to each other, brought into one place where a small team can see them.

What we'll cover

• Signals from four different products
• Cloud Functions or external automation
• Building it with CodeWords
• Crash reporting, which needs a release baseline
• Authentication events worth watching
• Firestore writes that should never happen
• Cost alerts, which arrive too late by default
• Staged rollouts, where the alerting has to keep up
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

Signals from four different products

Worth listing, because the useful integration draws from several and each behaves differently.

Crashlytics reports crashes and non-fatal errors, with velocity and affected-user counts, and this is where most mobile teams start.

Authentication has events for sign-up and sign-in that are available through functions rather than as a stream you can subscribe to externally.

Firestore and Realtime Database produce document and node change events, reachable through triggers.

Billing and usage live in the Google Cloud console, separately, and are the thing most likely to surprise a team.

Performance monitoring and App Check add their own signals on plans and configurations that include them.

The integration worth building picks a small number from across these rather than trying to forward any one of them wholesale.

Cloud Functions or external automation

Both work, and the division is clear once stated.

Cloud Functions for document and auth triggers. These fire inside Google's environment with low latency, and there is no external mechanism that subscribes to them directly.

External automation for anything scheduled, for anything crossing into other systems, and for anything you want maintained alongside your other workflows.

External automation for reporting, which needs no proximity to the data.

Avoid the trigger loop. A function that writes to the collection it watches is a classic and expensive mistake, and the bill arrives before the realisation.

Watch cold starts and timeouts in functions doing substantial work, which is a common reason a trigger-based notifier disappoints.

A reasonable pattern: a thin Cloud Function that forwards the event outward, and the logic, formatting, and routing built where you can see and maintain it.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which signal, what threshold, and who should be told.
3. Authorize the connection with a service account scoped to the project, and to your Slack workspace.
4. Describe the exceptions: a crash already known, a spike caused by a release, an auth pattern from your own testing.
5. Test against a non-production project and a test channel before anything reaches the team.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Crash reporting, which needs a release baseline

The signal most worth surfacing and the one most often configured badly.

Compare against the release, not against history. A new crash in the current version matters; the same crash that has existed for four releases is a backlog item.

Use crash-free users, not crash counts. A count rises with adoption, so a new release always looks worse, and the rate is what actually changed.

Alert on velocity. A crash affecting a rising share of sessions within hours of a release is the one that warrants stopping a rollout.

Say which version and which platform. A crash on one platform at one version is a different conversation from one affecting everybody.

Distinguish new from regressed. A crash that was fixed and has returned is worse news than a new one, and the two look identical without the history.

Send it where the mobile team is, not to a general engineering channel, since acting on it requires the people who ship the app.

Authentication events worth watching

A small set, and each indicates something.

A spike in sign-up rate is either a marketing success or an abuse pattern, and it is worth a glance either way.

Repeated failed sign-ins for one account, which may be an attack and may be somebody locked out.

Sign-ups from an unusual concentration of addresses or domains, which is the shape of automated account creation.

Account deletions rising, which is a product signal nobody watches because it appears in no dashboard by default.

A provider failing. If federated sign-in through one provider stops working, users simply cannot get in, and nothing reports it — a synthetic check is the only thing that catches it.

Firestore writes that should never happen

The category that finds real bugs, and it is worth framing as data quality rather than as alerting.

Documents missing required fields, written by a client version that predates them or by code that skipped validation.

Values outside plausible ranges — a negative balance, a date far in the future, a count that should never exceed a bound.

States that should not persist, such as an order that has been pending for a week.

Orphaned references left by a deletion that did not clean up.

Remember security rules do not apply to your automation. The Admin SDK bypasses them, so validation living only in rules does not constrain what a backend process writes, which is often how the bad documents got there.

Run these as a scheduled check reporting findings rather than as a per-write trigger, since the value is in the pattern and a per-document alert is noise.

Cost alerts, which arrive too late by default

Budget alerts in Google Cloud are informational and they do not stop anything, and they often arrive after a meaningful amount has been spent.

Reads are usually the cost in Firestore, and the biggest consumer is frequently a query nobody remembers writing.

Alert on the rate of change, not on reaching a budget threshold, since the rate tells you something is wrong while the threshold tells you it already happened.

Report by collection and by access pattern where you can, so the alert points at the cause.

Watch after every release. A change to a query is the usual cause of a sudden cost increase, and correlating the two is straightforward if somebody is looking.

Staged rollouts, where the alerting has to keep up

Mobile releases go out gradually, and the alerting has to understand that or it reports the wrong thing.

Segment by version. A crash rate across all users is dominated by the versions most people are on, which hides a serious problem in the small share who have the new one.

Expect small numbers early. A rollout at one per cent produces few sessions, so rates are volatile and a minimum-volume threshold prevents alarm at noise.

Compare the new version against the previous one at the same point in its rollout, not against its eventual steady state.

Watch the first few hours closely and then relax. The decision the alerting supports — halt or continue — is made early, and continuing to alert at the same sensitivity afterwards is noise.

Include the rollout percentage in the message, since a crash rate means something different at one per cent than at fifty.

Say what to do. "Consider halting the rollout" is an instruction; "crash rate elevated" leaves somebody to work out whether it is their decision.

Making it survive

Make it idempotent, keyed on the event, since function invocations can repeat.

Do not alert from inside the thing you are monitoring — a notifier that depends on the failing service will be silent exactly when needed.

Deduplicate crash alerts so one issue produces one message with updates, not a message per occurrence.

Handle the missing field explicitly rather than treating absent as zero.

Report the outcome. Alerts sent, checks run, and anything suppressed as known.

Limits worth knowing about

Cloud Functions have cold starts and timeouts, which affects anything doing substantial work in a trigger.

Firestore charges per document read, so a scheduled scan of a whole collection is expensive and gets more so as the collection grows.

Auth events are available through functions, not as an external subscription, so something has to run inside the project.

Security rules do not constrain the Admin SDK, which is worth remembering when deciding what your automation is allowed to do.

Slack rate limits apply, which matters during a crash spike when volume is highest.

What to set up first

Crash velocity alerting on the current release: a crash affecting a rising share of sessions in the hours after a rollout, sent to the mobile team with the version and platform named. It is the signal with the shortest useful window, since the decision it supports is whether to halt a staged rollout.

Two habits make the difference. Alert on crash-free rate rather than crash count, since counts rise with adoption and always make a new release look worse. And distinguish a returning crash from a new one, because a regression is a different conversation and the two are indistinguishable without the history.

Frequently asked questions

Cloud Functions or external automation?

Functions for Firestore and auth triggers, since nothing external can subscribe to them. External automation for scheduled checks, reporting, and anything crossing into other systems. A thin function forwarding outward gets both.

What crash metric should alerts use?

Crash-free users or sessions, not crash counts. Counts rise with adoption, so every release looks worse than the last. The rate is what actually changed, and velocity within hours of a rollout is what supports a decision.

Why is our Firebase bill rising?

Usually Firestore reads, and usually a query returning far more documents than it uses or a scheduled job scanning a whole collection. Alert on the rate of change rather than on reaching a budget, since the budget alert arrives after the money is spent.

Can I alert on bad data in Firestore?

Yes, as a scheduled check rather than a per-write trigger. Report documents missing required fields, values outside plausible ranges, and states that should not persist. Security rules do not constrain the Admin SDK, which is often how those documents arrived.

What authentication signals matter?

Sign-up spikes, repeated failures on one account, concentrations suggesting automated account creation, and a federated provider that has stopped working. The last one is invisible without a synthetic check and stops users signing in entirely.

Where should crash alerts go?

To the mobile team's channel, not to general engineering. Acting on a crash requires the people who ship the app, and a crash alert in a channel where nobody can act on it is a message that gets muted.

How do I avoid an expensive trigger loop?

Never let a function write to the collection it watches. It is the classic Firebase mistake, it compounds silently, and the bill is usually the first thing that tells you about it.

How should alerting handle a staged rollout?

Segment by version, require a minimum session volume so early small numbers do not cause alarm, compare the new version against the previous one at the same rollout stage, and include the rollout percentage in the message. A blended rate across all versions hides the problem entirely.

What should a crash alert actually say?

The version, the platform, the rollout percentage, whether the crash is new or returning, and what decision it supports. "Consider halting the rollout" is actionable; "crash rate elevated" leaves the recipient working out whether it is their call.

Related reading

• Firebase and CodeWords
• Automating Slack alerts from monitoring tools
• CodeWords integrations and templates