Skip to content

Firebase Cloud Messaging errorFCM “UNAVAILABLE” (503) and “INTERNAL” (500)

Your server sends a push and Firebase Cloud Messaging answers HTTP 503 UNAVAILABLE or HTTP 500 INTERNAL, or the Admin SDK throws messaging/server-unavailable or messaging/internal-error. These are server-side errors, and Firebase says to retry them, but only in a specific way. Here is what Firebase says, in its words, or hand it over at a fixed price.

Rather hand it over? App Fix Ticket: One reproducible bug in an existing mobile or web app, diagnosed and fixed.

Full refund if Simon can’t take it on once he sees your project, or if you cancel before work starts. Refund terms.

Short answer

FCM could not process the request in time (503) or hit an unknown error (500). Check the FCM status dashboard for a disruption, then retry the same request with exponential backoff and random jitter, honoring any Retry-After header. Do not retry 400, 401, 403 or 404 errors, and stop retrying a message once it is no longer timely. If 500s persist, contact Firebase support.

Rather not fix it yourself? App Fix Ticket starts with a fixed-price diagnosis, then a fixed price for the fix before any fix work.

What is behind the error, and the fix

  1. 01

    FCM is overloaded or has a disruption

    “The server couldn't process the request in time.” Firebase, FCM ErrorCode (UNAVAILABLE)

    UNAVAILABLE means FCM did not answer in time. Look at the FCM status dashboard at status.firebase.google.com before you change code. If there is an ongoing disruption, queue the messages and resend them with backoff once it clears.

  2. 02

    Retrying at once, or all messages together

    “Honor the Retry-After header if it is included in the response from the FCM Connection Server.” Firebase, FCM ErrorCode (UNAVAILABLE)

    An instant retry, or a loop that resends every failed message at the same moment, adds load right when FCM is short of it. Wait before the first retry, double the wait each time, and add a random amount per message. If you call the HTTP v1 API directly, read the Retry-After header and wait at least that long.

    import { initializeApp } from 'firebase-admin/app';
    import { getMessaging } from 'firebase-admin/messaging';
    
    initializeApp();
    
    const RETRYABLE = ['messaging/server-unavailable', 'messaging/internal-error'];
    
    async function sendWithRetry(message, attempt = 0) {
      try {
        return await getMessaging().send(message);
      } catch (err) {
        if (!RETRYABLE.includes(err.code) || attempt >= 5) throw err;
        const delay = 10_000 * 2 ** attempt + Math.random() * 1_000;
        await new Promise((r) => setTimeout(r, delay));
        return sendWithRetry(message, attempt + 1);
      }
    }
  3. 03

    Retrying errors that will never succeed

    “For 400, 401, 403, 404 errors: abort, and do not retry.” Firebase, Scale up with FCM (Handling retries)

    A retry loop that treats every failure as temporary keeps resending bad tokens, bad payloads and auth errors. Those requests add traffic and never go through. Retry only 500 and 503 errors with backoff, and 429 after the Retry-After wait; drop or fix the rest.

  4. 04

    An INTERNAL (500) error that keeps coming back

    “If the error persists, please contact Firebase support.” Firebase, FCM ErrorCode (INTERNAL)

    A 500 is an unknown error on FCM’s side. Retry it the same way as a 503. If it keeps failing for the same request after backoff and the status dashboard is clear, collect the request and the full error response and send them to Firebase support.

Checked against the vendor’s docs on : Firebase docs: FCM HTTP v1 ErrorCode; Firebase docs: FCM error codes (Admin SDK); Firebase docs: Scale up with FCM.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

“Very responsive, attentive to fixing bugs, and completed the project as needed! Thank you!”
A buyer in the United States, July 2022. Shopify on Fiverr
All 127 Fiverr reviews

Related: FCM QUOTA_EXCEEDED · FCM THIRD_PARTY_AUTH_ERROR · FCM registration token not registered · FCM invalid registration token

Questions

More on this error

How long should the timeout be on an FCM send?

At least 10 seconds. Firebase says most of FCM’s internal calls use a 10 second timeout, so a shorter client timeout can give up on a request FCM would have answered.

How long should I keep retrying?

Not forever. Firebase recommends a maximum interval after which you drop requests that are no longer timely. A reminder that arrives an hour late can do more harm than one that never arrives, so set a cut-off per message type.

Can retrying too hard get my project denylisted?

It can. Firebase warns that senders that cause problems risk being denylisted, which is why it asks for exponential backoff with jitter and for honoring Retry-After.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.