This page provides troubleshooting help and answers to frequently asked questions about Cloud Messaging.
Firebase Cloud Messaging provides a complete set of messaging capabilities through its client SDKs and HTTP server protocol. For deployments with more complex messaging requirements, FCM is the right choice.
The Notifications composer is a lightweight, serverless messaging solution built on Firebase Cloud Messaging. With a user-friendly graphical console and reduced coding requirements, the Notifications composer lets users send messages to re-engage and retain users, foster app growth, and support marketing campaigns.
| Capabilities | Notifications composer | Cloud Messaging | |
|---|---|---|---|
| Target | Single device | ||
| Clients subscribed to topics (i. e. weather) | |||
| Clients in predefined user segment (app, version, language) | |||
| Clients in specified analytics audiences | |||
| Clients in device groups | |||
| Upstream from client to server | |||
| Message Type | Notifications up to 2kb | ||
| Data messages up to 4kb | |||
| Delivery | Immediate | ||
| Future client device local time | |||
| Analytics | Built-in Notifications analytics collection and funnel analytics |
You can use Firebase Cloud Messaging as a standalone component, without using other Firebase services.
When it looks like devices haven't successfully received messages, check first for these two potential causes:
Foreground message handling for notification messages. Client apps need to add message handling logic to handle notification messages when the app is in the foreground on the device. See the details for iOS and Android.
Network firewall restrictions. If your organization has a firewall that restricts the traffic to or from the Internet, you need to configure it to allow connectivity with FCM in order for your Firebase Cloud Messaging client apps to receive messages. The ports to open are:
- 5228
- 5229
- 5230
FCM usually uses 5228, but it sometimes uses 5229 and 5230. FCM doesn't provide specific IPs, so you should allow your firewall to accept outgoing connections to all IP addresses contained in the IP blocks listed in Google's ASN of 15169.
When your app is in the background, notification
messages
are displayed in the system tray, and onMessageReceived is not called. For
notification messages with a data payload, the notification message is displayed
in the system tray, and the data that was included with the notification message
can be retrieved from the intent launched when the user taps on the
notification.
For more information, see Receive and handle messages.
FID (Firebase Installation ID) is the identifier of an app instance. By default, Firebase Installation data is backed up and restored. So in the restoration case, the restored app instance and the original app instance share the same FID. Since FCM only stores one token per FID, if both the original app instance and the restored app instance are in use, then when one app instance registers with FCM, the other app instance's token is removed, which causes 404 errors.
We recommend developers to do the following in their app:
- Exclude
Firebase installation data in backup. The Firebase installation data is stored
in a
PersistedInstallation....jsonfile. The filename is a constant for an app. For example,<exclude domain="file" path="PersistedInstallation.W0R...GQ.json" />
No. Firebase Cloud Messaging switched to the HTTP/2-based APNs protocol in 2017. If you're using FCM to send notifications to iOS devices, there should be no action required on your part.
FCM quotas and limits
This use case cannot be supported. You must spread your traffic out over 5 minutes.
Unfortunately, we cannot grant quota increases for this reason. You must spread your traffic out over 5 minutes to avoid spiky traffic.
We recommend that you start sending the notifications at least 5 minutes prior
to the event. Alternatively, send data
messages
and implement your platform's analog of onMessageReceived handler to schedule
local notifications ahead of time.
See Google Cloud guidance on how to chart and monitor quota metrics.
While we understand that quota limits can be challenging, quotas are vital to keeping the service reliable and we can't grant exemptions. Use retries to properly handle 429 errors.
Your quota increase request depends on your use of FCM. In any case, you can expect an answer in a few business days. In some cases, there may be some back-and-forth regarding your usage of FCM and various circumstances, which can prolong the process. If all requirements are met, most requests will be handled within 2 weeks.
You can request additional quota to support an event lasting up to 1 month. File the request at least 1 month in advance of the event and with clear details on when the event starts and ends, and FCM will make every practical effort to fulfill the request. If granted, these quota increases will be reverted after the event's end date.
While Google won't do so lightly, quotas may be changed as needed to protect the integrity of the system. When possible, Google will notify you in advance of such changes. Keep your Cloud MSA contacts updated to increase the chances of receiving service announcements.
FCM legacy API deprecations
Server side APIs deprecated in September 2026
All the InstanceId server APIs and the device group feature are deprecated and will be decommissioned on September 29, 2027. The following table shows more details about the deprecated APIs/features and the action required.
| API Name | API Endpoint | Intended Use | Customer Impact | Action Required |
|---|---|---|---|---|
| InstanceId info API | https://iid.googleapis.com/iid/info | Getting info related to an InstanceId / FCM token | Requests to this API will start failing after September 29, 2027. | For customers using the API for token validation, use FCM V1 send API and set validate_only to true.
For customers using the API for getting topic subscription info, migrate to the new topic subscription API. |
| InstanceId topic subscription API | https://iid.googleapis.com/iid/v1/…/rel/topics https://iid.googleapis.com/iid/v1:batchAdd https://iid.googleapis.com/iid/v1:batchRemove |
Subscribing token(s) to a topic via the legacy topic subscription API. | Requests to these API will start failing after September 29, 2027. | Migrate to the new FCM topic subscription server API for topic subscription and unsubscription. |
| InstanceId batch import API | https://iid.googleapis.com/iid/v1:batchImport | Creating FCM tokens for iOS in a batch on the server side. | Requests to this API will start failing after September 29, 2027.
Creating FCM registrations from APNs tokens on the server side won't be supported. |
You can use Apple's APNs service to send notifications using APNs tokens.
To get extra benefits provided by FCM, integrate your app with FCM iOS SDK, which will create FCM registrations on the client. |
| Device group management API | https://fcm.googleapis.com/fcm/notification https://fcm.googleapis.com/gcm/notification https://fcm.googleapis.com/iid/notification https://fcm.googleapis.com/notification |
Adding / removing/ retrieving device group members. | Requests to this API will start failing after September 29, 2027. | See the guidance for migrating off the feature.
Messages can still be sent to individual FCM registrations instead of group tokens. |
| Device group send | https://fcm.googleapis.com/v1/projects/…/messages:send | Sending messages to device groups using group notification_key. | This API will continue working but it won't support device group tokens after September 29, 2027. |
If you are using earlier versions of Firebase Admin SDK to manage topic subscriptions, you will be impacted by the deprecation. You will need to upgrade your Firebase Admin SDK to the following versions:
| Platform | Admin SDK version being impacted | Admin SDK version to be upgraded to |
|---|---|---|
| Node.js | <=14.4.0 | >=14.5.0 |
| Python | <=7.6.0 | >=7.7.0 |
| Java | <=9.10.0 | >=9.11.0 |
| Go | <=4.21.0 | >=4.22.0 |
| .NET | <=3.6.0 | >=3.7.0 |
No. You have 12 months to migrate from the deprecated APIs to alternatives without any service downgrade. We strongly recommend you to plan the migration as early as possible so you won't be impacted by the decommissioning.
You are expected to receive errors when calling deprecated APIs after September 29, 2027.
New users can onboard the deprecated APIs/features before January 1st, 2027. After January 1st, 2027, new users won't be able to use the deprecated APIs. Users who are using the deprecated APIs can continue using them until September 29, 2027.
AndroidConfigV2 FAQ
FCM plans to continue supporting v1 AndroidConfig payloads for
multiple years following the General Availability (GA) release of
AndroidConfigV2. While the migration timeline spans multiple years,
AndroidConfigV2 provides more predictable notification delivery, and you're
encouraged to migrate as soon as possible.
AndroidConfigV2 will be supported on all Android versions that are supported
by Google. All but 10+ year old devices will be supported when the legacy v1 API
is decommissioned.
Yes. When you send an AndroidConfigV2 request, FCM and GMS Core
automatically translate the payload for devices running older client SDKs or for
apps that haven't overridden onNotificationReceived() or
onBackgroundSyncReceived() yet, delivering it using onMessageReceived().
By returning a NotificationResponse to the
open-source FCM SDK, or using FcmNotificationManager:
- Your app receives a protected execution window to decrypt or customize the notification.
- If your app runs out of time, GMS Core ensures timely delivery by posting
the backup notification you configured in
remote_notification.notification.
No. Unlike legacy v1 notification messages, AndroidConfigV2 does not split
message routing based on whether your app is in the foreground or background.
When you send a RemoteNotification, the notification is displayed
automatically in both states unless you set mutable_content: true and
explicitly silence it in onNotificationReceived() using
NotificationResponse.createEmpty().
When mutable_content: true is set on a RemoteNotification, your app has up
to 20 seconds inside onNotificationReceived() to
decrypt payloads, fetch small assets (such as avatars), or contact your app
server before returning a NotificationResponse. If the callback exceeds
20 seconds, execution is cancelled and GMS Core
automatically posts a fallback notification based on the
remote_notification.notification payload.
Apps can suppress a RemoteNotification by returning
NotificationResponse.suppress() from onNotificationReceived(). For
example, when a chat is muted, a sender is blocked, or an end-to-end encrypted
payload fails validation.
- In the background: Your app can suppress up to
25% of received
RemoteNotificationmessages over a rolling window. If your app's background suppression rate exceeds 25%, GMS Core automatically renders and posts the fallback notification from theremote_notification.notificationpayload. - In the foreground: You're free to suppress all Remote Notifications while active in the foreground. For example, to display an in-app toast or update an open chat screen instead of posting a system notification.
Yes. Use the following to cancel or post multiple notifications:
- Cancel a single notification: Return
NotificationResponse.createCancel(tag, id)fromonNotificationReceived()to dismiss a previously posted notification. - Post multiple notifications or combine cancels and posts: Call
getFcmNotificationManager(message)insideonNotificationReceived()to invokepostNow(tag, id, notification)andcancelNow(tag, id)multiple times, and returnmanager.finished()when complete.
Yes, custom RemoteViews will work with AndroidConfigV2.
onNotificationReceived() returns a standard Android Notification object, all
standard Android notification APIs, such as setCustomContentView(), remain
supported. Note that RemoteViews and Views are in maintenance mode, and it's
recommended to migrate to Compose.