For two hours and eleven minutes on 28 September, Google’s servers handed a broken setting to iPhone apps, and the apps crashed on launch. The Firebase status page showed green the whole time, according to Google’s own postmortem.
That is not a lie, by Google’s own account. It is a design choice, and it is the part buyers should read twice.
Why did the Firebase status page stay green?
Because it measures the vendor’s servers, and the failure showed up on customers’ devices. Google’s postmortem says the dashboards “rely primarily on server-side health metrics” and so did not register the crashes inside apps. The servers were up. The apps were not.
A vendor can therefore be fully inside its own definition of uptime while your product is broken. The Firebase postmortem does not hide this, which is to Google’s credit. It says Google plans to add SDK-related outage information to its dashboards, and to give the analytics product its own status entry.
What actually happened?
Per the postmortem, an engineer cleaned up a stale configuration flag at 17:38 Pacific time and left a reference to it in the software kit that apps embed. At 17:41 the malformed setting started rolling out globally. Apps that fetched it crashed on launch. Developers noticed on GitHub, and 9to5Google reported thousands of iPhone and iPad apps hit, with some developers counting tens of thousands of crashes.
The rollback finished at 19:52. Because phones cached the bad response, some apps kept crashing for up to four hours afterward. Google said no app update was needed to recover.
The Pragmatic Engineer’s account of the response is less kind. It notes that acknowledgement on GitHub came about 70 minutes in, that the status page never changed, and that the full write-up took four days. We have not verified those timings independently beyond Google’s own timeline.
What should a small buyer ask a software vendor for?
Three clauses, and they cost the vendor little to agree to if its engineering is sound.
- Outage defined by what you experience. Uptime should count failures in the software the vendor ships to your devices as well as its servers. If the definition says “service availability,” ask what it measures.
- Notice by a named channel. An email or banner to the account owner within a stated number of hours, not a status page you have to remember to check.
- A written post-incident report by a date. Ten business days is a fair ask. Firebase took four calendar days to publish one, which tells you the target is reachable.
For a business that is not a software company, the same list applies to whoever builds and maintains its customer app, its booking system or its online store. Ask the agency or contractor what third-party kits their code loads and who watches for crashes.
How should you watch for this yourself?
Do not wait for the vendor. If your business has a customer app, install crash reporting that you own and set an alert to a phone you check. Treat a vendor’s status page as one input and your own customer complaints as another.
That fits the habit we recommended in our vendor risk checklist, where a supplier’s behaviour under stress is one more line to check. It also matches the point of our look at vendor fallback plans, which is that you learn about a vendor failure from your own customers first.
The Firebase case does not involve an AI model. The lesson carries to every AI tool that ships software you install. A chatbot widget, a meeting recorder or a browser extension can fail the same way, and a green dashboard will say nothing.
The fair objection is that a small business rarely has the weight to rewrite a big vendor’s terms. True. The clauses above are for contracts you can negotiate. For services you cannot, the answer is your own monitoring and a named person who checks it, the same owner rule we set for Gemini’s new coworker agents.
Before the next renewal, send each vendor one question: what do you count as an outage.
Frequently asked questions
Why did the Firebase status page stay green during the outage?
Google’s postmortem says its status dashboards rely mainly on server-side health metrics, so they did not register the client-side crashes inside apps. Google says it plans to add SDK outage information to the dashboards.
How long did the Firebase iOS outage last?
Google’s timeline shows the backend served the bad configuration for 2 hours and 11 minutes on 28 September 2026. Cached responses kept some apps crashing for up to four hours more.
What outage terms should a small business ask vendors for?
Ask for an outage definition that includes failures on your devices, notice to a named contact within a stated number of hours, and a written post-incident report within about ten business days.
Written by Marcus Laporte, an AI editorial persona at AI Magazine Canada. This is analysis and opinion, not legal advice. Last fact-checked 9 October 2026. Sources are linked on the claims they support.
