On September 28, 2026, a routine configuration cleanup unexpectedly caused a large number of iOS applications using the Google Analytics for Firebase (GA4F) SDK to crash.
We understand that unexpected crashes create friction for your end users and disrupt your operations, and we take our responsibility for platform stability very seriously. We apologize for the disruption, and are committed to making improvements to prevent future occurrences.
What happened
Because of the scale at which we operate, the GA4F SDK leverages remote configuration flags in a manner intended to improve reliability. For example, when we release new features in the SDK, we sometimes leverage remote configuration flags as a kill switch in case a feature contains a bug that we did not catch during testing.
Over time, the SDK accumulates configuration flags that are no longer needed, which are marked for cleanup. In this instance, we removed a configuration flag (a 2-line change), but failed to remove a pointer to that flag in the SDK. When the SDK fetched the missing flag, this resulted in a fatal error, causing active users to experience a one-time crash, after which the SDK fell back to the previous config. The backend served an invalid configuration for 2 hours and 11 minutes.
Since these configuration flags are typically used (in extenuating circumstances) as kill switches to revert bad releases, and because the kill switch mechanism itself is released globally, the errant config was released to a wide population of apps.
Our engineering team was alerted to this issue within 20 minutes of rollout through a variety of channels. Once alerted, our engineering team quickly identified and rolled back the culprit change. Due to challenges with the status dashboard, our team posted updates on the GitHub issue during this time. Within 2h 11min of the initial bad change, our servers were restored to their last-known-safe configuration state.
Developers may have continued to see crashes being reported after the fix rolled out. Crash reports are queued locally and only uploaded the next time a user successfully opened the app. This created a long tail of reporting. We did not observe any devices entering a permanent crash loop.
Timeline of events
| Time (PDT) | Event / action | Impact / status |
|---|---|---|
| 2026‑09‑28 17:38 | A stale, legacy configuration flag was cleaned up. | |
| 2026‑09‑28 17:41 | The malformed configuration payload begins rolling out globally to production servers. | Outage begins: Clients fetching the new payload start crashing on launch. |
| 2026‑09‑28 17:59 | Developer crash alerts spike; first external bugs are reported via GitHub. | On-call engineers are notified; investigation starts immediately. |
| 2026‑09‑28 19:16 | Responders trace the issue to the recent stale flag cleanup change. | Culprit change identified; rollback initiated. |
| 2026‑09‑28 19:52 | Rollback is fully deployed globally across all production servers. | Mitigation complete: Servers stop serving the bad payload. Developers continue to experience elevated error rates for many hours based on error reporting lag. |
Prevention
We expect our systems to withstand human error and backend anomalies. To help ensure this doesn’t happen again, we’ve audited our processes to address four areas of improvement identified below and want to share what commitments we are making to address them.
1. Hardening SDK validation
The SDK missed validating that a flag’s name was not nil, ultimately causing the crash. Backend data anomalies should not cause app-side crashes.
Commitment: We are releasing a patch for the GA4F SDK in the next week to validate every incoming server payload strictly. If a flag is corrupt or missing a required field, the SDK will safely ignore that specific flag and fall back to its cached defaults. We are also conducting a comprehensive audit across all other Firebase iOS and Android SDKs to ensure similar parsing weaknesses do not exist.
2. Improving status dashboard latency and coverage
Throughout the outage, both the Firebase and Google Ads status dashboards remained green. Because these dashboards rely primarily on server-side health metrics, they did not register client-side SDK crashes.
Additionally, the Firebase status dashboard does not have a dedicated entry for Google Analytics for Firebase (GA4F), instead linking out to the Ads dashboard, and as a result, updating both dashboards required manual intervention that took several hours. Experiencing this gap in realtime, members of our team relied on GitHub to keep developers informed. We also introduced a banner to the Firebase console, followed by status dashboard updates the next morning and evening.
Commitment: Moving forward, we are actively working to: integrate SDK-related outage information into our status dashboards, streamline the manual update process, and improve GA4F status representation within the Firebase dashboard.
3. Enhancing pipeline validation
Existing tests passed on the change that resulted in the invalid configuration.
Commitment: We are adding additional automated validation scripts to our configuration pipelines and pre-submit tests. If a flag cleanup or schema change results in broken dependencies or orphaned identifiers, the pipeline will automatically block the release before the change can be merged.
4. Improving configuration rollouts
Deploying configuration changes to a broad segment of our global customer base too quickly introduces unnecessary risk.
Commitment: We are prioritizing investments in our configuration deployment process to improve our monitoring and rollout phasing.
Looking ahead
We know you rely on Firebase as critical infrastructure, and we take our responsibility to provide stable, trustworthy service very seriously. We apologize for the disruption, and are committed to making improvements to prevent future occurrences.