Firebase Outage: When Vendor Code Crashes Your App

On 29 September 2026, from 07:41 to 09:52 WIB, iOS apps that bundle Google Analytics for Firebase crashed on launch after Google deleted one setting on its own servers. The apps' own code was fine. Vendor code inside your app shares the app's fate, so you need your own off switch and your own warning signals.

This article covers what Google's incident report says, why a tool that only counts visitors could close a checkout screen, and what to check in the apps your business depends on.

What happened on 28–29 September?

Google published its postmortem, the after-incident report, on the Firebase blog on 2 October 2026. The timeline, converted to Indonesian time:

Google's own clock is Pacific time, where this was the evening of 28 September. In Indonesia it landed on a Tuesday morning, when people open their banking, ride, shopping and hotel apps on the way to work. The bad configuration was served for 2 hours and 11 minutes.

The cause was small. Google removed a flag in a two-line change, but the analytics code running inside iOS apps still pointed at it. When that code received a configuration with the flag missing, it tried to store an entry with an empty name, and iOS terminated the whole app. The GitHub issue developers opened shows the exact error: key cannot be nil, meaning "you can't file something under a blank label". One developer counted 56 crashes from 56 users in the first 18 minutes. Others reported totals around 20,000 and 110,000 crash events.

The postmortem adds two details that matter for scale. Each active user saw a one-time crash, after which the code fell back to the previous configuration, and Google saw no device stuck in a permanent crash loop. And Google's existing tests had passed on the change.

Why can an analytics tool close your checkout screen?

An SDK, a ready-made package of vendor code you embed in your app, is not a separate program. It runs inside your app's process, with the same memory and the same fate. Think of a tenant cooking in a room of your house: if their stove catches fire, your whole house burns, not only their room.

So the analytics package that only counts screen views shares a lifeline with the payment screen, the booking form and the login. When it crashes, iOS shuts everything down. The user doesn't know or care which vendor was at fault. They see your logo, then their home screen.

The second detail is the uncomfortable one. Firebase uses these server-side flags as a kill switch, a remote off button that lets Google disable a buggy feature without waiting for a new app release. Here the safety mechanism itself became the trigger. A vendor that can change how its code behaves remotely can change how your app behaves, at any hour, without passing through your testing or Apple's review.

This is not new. On 10 July 2020, a bad server response to Facebook's iOS SDK crashed Spotify, Pinterest and other major apps on launch, as 9to5Mac reported, two months after a similar incident in May. The same shape repeats: a vendor server sends data the embedded code didn't expect, and someone else's app dies.

Why did the status page stay green?

Both the Firebase and Google Ads status dashboards stayed green for the whole incident. Google's explanation: the dashboards are fed by server-side health metrics, and the servers were healthy. They answered every request quickly, with a configuration that crashed the apps receiving it.

The first public signal came from developers on GitHub, not from Google's status page. Status pages measure the vendor's servers. Nothing on them measures whether your app opens.

Crash reports added a second delay. iOS apps queue a crash report on the phone and upload it the next time the user opens the app. That is why, as Google noted, developers kept seeing crashes for hours after the fix. For a team that shipped its own update that week, the obvious and wrong conclusion is "our release broke something", followed by an unnecessary rollback.

How do you tell "our bug" from "their bug"?

Three questions settle most cases within fifteen minutes:

Write these three questions into your incident runbook, the step-by-step sheet the on-call person follows. Without them, the first hour goes to re-checking your own code.

What should you put in place?

1. Know what vendor code is inside each app

List every SDK in each app, why it is there, who owns the decision to keep it, and whether it talks to a vendor server at startup. Analytics, crash reporting, advertising, chat widgets and payment SDKs are the usual suspects. Any package you can't justify is risk without benefit; remove it.

2. Keep your own off switch, checked before vendor code starts

Have the app read a small settings file from your own server, cached on the phone, before it initialises optional SDKs. If a vendor package starts crashing, you flip one value and the next launch skips that package entirely. No app store review, no waiting for the vendor's rollback.

Two rules make this switch trustworthy. Keep it on infrastructure separate from the vendor it controls, and make the app treat a missing or malformed setting as "use the last good value". Otherwise you have rebuilt the same failure in your own code.

3. Watch crashes from your side, not the vendor's

Alert on crash-free sessions, the share of app sessions that end without a crash, with a threshold that pages someone within minutes. Pair it with a server-side signal you control: launches or logins hitting your API per minute. If launches spike while completed logins drop, users are opening the app repeatedly and failing. The basics of setting thresholds and routing alerts are in monitoring and alerting for small systems.

4. Follow your vendors where they actually talk

Watch the GitHub repositories and release notes of the SDKs you depend on. In this incident, GitHub carried the real-time news while the status page stayed silent. Google shipped hardening in Firebase iOS SDK 13.0.0, and noted that the GoogleUtilities 8.1.4 update improves resilience against bad server data. Schedule the upgrade like any other change: test it, then release.

Does this apply to systems you run yourself?

Yes, and this is the more valuable lesson. If you push settings to devices you operate, such as kiosks, signage players, Android TV boxes or IoT gateways, you are Google in this story. Every setting you change on the server is code that reaches all devices at once, without going through your usual release testing.

Google's commitments after the incident are a good checklist for anyone in that position:

• Validate on the device. A missing or malformed setting should be ignored, with the device keeping its last known good value. Bad server data should never crash a client.
• Roll out in stages. Send a change to a small group of devices first, watch them, then widen. If something breaks, it breaks a few screens.
• Check who still reads a setting before deleting it. Remove it only once no deployed device depends on it.
• Monitor the client, not only the server. A server that answers fast while every device crashes is not healthy.

I cover staged updates for screens in the field in managing a fleet of Android TV boxes.

What to check this week

• List every vendor SDK in each of your apps, with an owner and a reason to keep it.
• Check whether your iOS apps use Firebase Analytics, and plan the upgrade to Firebase 13.0.0 or later through your normal testing.
• Confirm there is a crash alert that wakes a person, not just a dashboard.
• Add an off switch for optional SDKs, stored on your own infrastructure.
• If you push settings to devices, confirm they survive a missing or malformed value.

Every vendor package you add saves development time and adds a dependency your app cannot escape at runtime. Keep the list short, keep an off switch, and measure from where your users are.