Firebase Slack integration: Crashlytics alerts in Slack, or push and Slack from one API call.

Firebase offers basic alerting integrations that send the default Crashlytics alerts to Slack, Jira and PagerDuty, as Firebase's Crashlytics alerts documentation describes (checked 12 October 2026). The page covers Crashlytics alerts only.

1. Create a Slack incoming webhook, following Slack's guide to sending messages with incoming webhooks.
2. In the Firebase console open Settings > Integrations, choose Install on the Slack card, enter the webhook URL, a default channel and the name messages should post under, then choose Verify & save. A confirmation message appears in the default channel.
3. Open Settings > Alerts, find the Crashlytics card, pick an app and the Slack channel for it, and choose for each alert type whether it goes to Slack. Repeat for each app.

The alert types are new fatal issues, new non-fatal issues, regressed issues, trending issues and increasing-velocity issues. Firebase sends Slack alerts for regressed and increasing-velocity issues by default, and the default channel can be overridden per app or per alert.

This page does not claim that Notifly forwards Crashlytics alerts, or any other Firebase alert, to Slack.

The other question behind the same search: something happens in your product, such as a failed payment, and the person involved should get a push notification on their phone and a Slack message, without two integrations in your backend. In Notifly that is one workflow with a Push step and a Chat step, and one trigger.

1. Connect Firebase: in the dashboard open Integration Store, choose Connect Provider, open the Push tab and connect Firebase Cloud Messaging (FCM) with a service account key from your Firebase project, as the FCM integration guide shows.
2. Connect Slack: in the same sheet open the Chat tab and connect Slack with your own Slack app's credentials, as the Slack integration guide shows.
3. Build the workflow: add a Push step and a Chat step, and write both messages with the trigger's payload, such as {{payload.plan}}.
4. Register each user's FCM token and give them a Slack destination, an incoming webhook or a connected Slack user, then trigger the workflow.

// npm install @notiflyio/api@0.1.26
import { Notifly } from "@notiflyio/api";

const secretKey = process.env.NOTIFLY_SECRET_KEY;
if (!secretKey) throw new Error("NOTIFLY_SECRET_KEY is not set");
const notifly = new Notifly({ security: { secretKey } });

// Once per subscriber: the FCM registration token your app sent to your backend, and the Slack
// incoming webhook their Slack messages go to.
await notifly.subscribers.create({ subscriberId: "user_123" });
await notifly.subscribers.credentials.registerToken({
  subscriberId: "user_123",
  providerId: "fcm",
  registerSubscriberDeviceTokenRequestDto: { token: "fcm-registration-token-from-the-app" },
});
await notifly.subscribers.credentials.update(
  {
    providerId: "slack",
    credentials: { webhookUrl: "https://hooks.slack.com/services/T0000000/B0000000/XXXXXXXXXXXXXXXXXXXXXXXX" },
  },
  "user_123",
);

// Any time after that: one trigger runs the workflow's Push step and its Chat step.
await notifly.trigger({
  workflowId: "payment-failed",
  to: "user_123",
  payload: { plan: "Pro", severity: "urgent" },
});

Notifly sends one FCM message per registered device token, and a subscriber with no token is skipped and recorded in the activity feed. Slack delivery works as Send Slack notifications from your app describes.

Destinations belong to subscribers. Address one trigger to a user and to a team subscriber, and each gets what they have a destination for: the user's devices receive the push, and the team's Slack channel receives the message.

// "oncall" is a subscriber with a Slack webhook and no FCM token; "user_123" has the reverse.
// The push goes to user_123's devices, the Slack message to oncall's channel.
await notifly.trigger({
  workflowId: "payment-failed",
  to: ["user_123", "oncall"],
  payload: { plan: "Pro", severity: "urgent" },
});

• Routing with step conditions. Open Step conditions on a step to run it only when a payload, subscriber.data or context field matches, for example the Chat step only when payload.severity equals urgent. A step whose conditions fail is skipped and the activity feed records it.
• Preferences at send time. Before each step runs, Notifly checks the subscriber's preferences for that workflow and channel, so someone who muted Slack still gets the push, and the reason a step was skipped is recorded.
• Digests. Put a digest step ahead of the Push or Chat step when a burst of events should arrive as one message.
• Clean token lists. Tokens FCM rejects as unregistered or invalid are removed from the subscriber by default.
• Delivery status. Every message gets execution details in the activity feed, including the response or error FCM or Slack returned.