At 20:57 on the night of March 31, something went wrong inside Baidu's cloud. Within minutes, over 100 Apollo Go robotaxis — Level 4 autonomous vehicles with no human safety drivers — simultaneously stopped in the middle of Wuhan's expressways, intersections, and elevated roads. Passengers were locked inside vehicles that wouldn't move. SOS buttons didn't work. Customer service lines jammed. Traffic piled up behind frozen machines that made no effort to pull over. By the time police cleared the last stranded cars, the incident had become the most dramatic demonstration yet of a structural vulnerability that every robotaxi operator in the world shares: when the cloud goes down, the fleet goes with it.
The Night It Happened
The first reports appeared on Chinese social media platforms Weibo and Douyin shortly before 9 PM local time on March 31. Videos and photos circulated showing white Apollo Go vehicles halted on major roads and elevated expressways, hazard lights flashing, completely immobile. The cars weren't pulled over to the shoulder. They had stopped in active lanes — some in the fast lane, some blocking the entrance to a hospital in Wuhan's Hanyang district, some straddling lane markings on elevated highways with traffic streaming past on both sides.
One dashcam recording posted to RedNote showed a driver passing 16 stalled Apollo Go vehicles in the span of 90 seconds. The footage showed the driver braking sharply and switching lanes repeatedly to avoid the frozen cars. Multiple collisions occurred. In one documented case shared on RedNote, a man driving over 40 mph could not react in time when the car ahead of him swerved to avoid a stopped robotaxi — he rear-ended the autonomous vehicle, tearing off his SUV's front-right fender. At least two other rear-end collisions were documented in photos and videos posted that same night.
Inside the stalled cars, passengers faced a different kind of ordeal. A college student identified only as He told Wired she was trapped with two friends for roughly 90 minutes after her Apollo Go malfunctioned and stopped multiple times before finally coming to rest at an intersection in eastern Wuhan. The in-car display told passengers to remain seated with seatbelts on and wait for a company representative "in five minutes." No one arrived. It took 30 minutes to reach a Baidu customer representative on the phone — who only said the issue had been escalated. The three passengers eventually let themselves out through an unlocked door.
Other passengers fared worse. Multiple riders reported pressing in-car SOS buttons that simply returned an error: "unavailable." One posted on RedNote alongside a video of a non-functional SOS button: "Apollo Go, you really owe me an apology." The Wuhan Municipal Public Security Bureau's Traffic Management Bureau issued an official statement confirming the incident began at 20:57 on March 31, identified a preliminary cause as "system malfunction," and confirmed that traffic police were dispatched alongside Apollo Go staff to evacuate passengers vehicle by vehicle. By the early hours of April 1, all stranded passengers had been safely removed from their cars.
The Architecture Problem
Baidu has not publicly confirmed what triggered the outage, and the investigation remains ongoing. But industry analysts pointing to the most likely cause aren't finding much mystery in it. Apollo Go, like virtually every commercial robotaxi operation in the world, runs on a centralized cloud architecture. That cloud manages routing, navigation data, over-the-air map updates, remote assistance requests, and the software systems that allow fleet operators to monitor vehicle status in real time. It is also where the "safe stop" mechanism — the failsafe designed to halt a vehicle if something goes wrong — is controlled.
The problem is what happens when that centralized system itself fails. Industry analysts suggest the Wuhan outage may have been triggered by an abnormality in cloud communication or a vulnerability in the system's algorithms, causing vehicles to activate the safe-stop mechanism fleet-wide. In a world with one or two cars, that would be an inconvenience. Across 100 simultaneous vehicles in a city of 12 million people, it became a cascading traffic emergency.
The safe-stop mechanism is supposed to protect passengers when a vehicle encounters a situation it cannot handle. It worked, in a narrow technical sense — the cars stopped. What it was not designed for was the scenario in which stopping itself creates danger. A robotaxi that halts in a fast lane because its cloud connection failed is not a vehicle in "safe" mode. It is an obstacle. The distinction matters enormously when you have over 1,000 vehicles in a single city, as Baidu does in Wuhan, and a growing percentage of those vehicles are operating without a human backup driver.
When the Safety Nets Fail
What made the Wuhan incident particularly alarming was not just the scale of the failure — it was the simultaneous collapse of the redundant safety systems that are supposed to activate when a vehicle breaks down.
The in-car SOS button is the last-resort safety mechanism for any passenger unable to exit a malfunctioning vehicle. On the night of March 31, it was nonfunctional in multiple vehicles during the event that made it most necessary. Customer service lines — the second layer of support — became unreachable as hundreds of simultaneous calls flooded the system. The vehicles' self-reporting to fleet management was either delayed or overwhelmed. The result was that passengers had no reliable channel to call for help from inside a stranded machine sitting in live traffic.
This failure cascade is distinct from the more commonly discussed technical challenge of whether a self-driving car can navigate a construction zone or recognize a hand signal from a police officer. Those are edge case detection problems. What happened in Wuhan is a systems resilience failure — the kind that engineers design redundancies for but that proves far harder to test at commercial fleet scale. When the same cloud infrastructure that powers navigation also powers emergency response, a single failure vector can simultaneously disable both the vehicle and every mechanism designed to help when the vehicle breaks down.
A Pattern Taking Shape
The Wuhan outage did not arrive without precedent. In December 2025, a widespread power outage in San Francisco knocked out traffic lights across multiple neighborhoods — and caused a significant portion of Waymo's fleet to stall and block intersections. The Waymo cars were programmed to occasionally ping a remote assistance team for a "confirmation check" before proceeding through dead traffic lights. During the blackout, the cellular network was also degraded, causing a surge of simultaneous remote assistance requests the team couldn't clear fast enough. The result was a traffic jam caused not by car failure but by a fleet of cars collectively waiting for human permission to proceed.
The Baidu incident fits a recognizable archetype — also well documented in TTN's earlier reporting on Waymo's dependence on police and emergency responders as a backstop when vehicles can't move. These are not software bugs being quietly patched between versions. They are architectural vulnerabilities inherent to fleets that depend on centralized, always-online infrastructure to maintain situational awareness and emergency response capability. Add to those the Baidu car that fell into a construction pit in Chongqing last August and the Pony.ai vehicle that caught fire on a Beijing road in May 2025, and a pattern emerges that goes beyond any single company.
China has been further ahead in autonomous vehicle deployment than any other market — and further ahead in discovering the ways things go wrong at scale. After a fatal assisted-driving crash involving a Xiaomi vehicle last year, Chinese regulators moved to tighten rules around autonomous driving features and restricted the term "autonomous driving" from being used in car advertisements. Those changes addressed the marketing around individual vehicle behavior. The Wuhan outage raises a different and harder question: what happens when an entire fleet fails at once, and the contingency plan doesn't scale?
Regulatory Pressure and Baidu's Response
Apollo Go moved quickly in the aftermath. The company suspended all robotaxi operations across Wuhan — its largest deployment with over 1,000 vehicles — and began working with traffic authorities and company staff to tow malfunctioning cars and evacuate stranded passengers. Service has been gradually resuming since, though Baidu has not provided a public explanation of the technical failure's root cause. The company did not respond to multiple media requests for comment in the days following the incident.
Wuhan's traffic management bureau confirmed the investigation is ongoing. Industry analysts and regulatory watchers anticipate the incident will accelerate calls for mandatory redundancy requirements in autonomous fleet architectures — specifically, requirements for local onboard fail-safe systems that do not depend on cloud connectivity for emergency response. There are also growing calls for standardized incident reporting frameworks that require companies to disclose the scope, cause, and impact of fleet-wide failures within defined windows.
Baidu's global ambitions add another dimension to the regulatory pressure. The company has been aggressively expanding Apollo Go internationally, with plans to deploy more than 1,000 autonomous vehicles in Dubai over the coming years. The Wuhan incident will follow that expansion into new regulatory jurisdictions — some of which have far less experience managing the kind of real-time emergency response the Wuhan traffic police executed on the night of March 31.
What the Industry Needs to Fix
The Wuhan outage is a stress test that autonomous vehicle companies worldwide have been quietly hoping would never come at this scale. It came. The results are instructive.
The first gap is architectural: safe-stop mechanisms need to behave differently in a fleet-wide failure than in an individual vehicle failure. A single car stopping in a lane because its sensor detected an anomaly is manageable. A hundred cars stopping simultaneously because a cloud service went offline is an infrastructure emergency. The current design does not appear to distinguish between the two.
The second gap is in emergency systems redundancy. SOS buttons that rely on the same cloud infrastructure as navigation and routing are not independent safety systems — they are extensions of the primary system. True redundancy would require onboard cellular modules with dedicated emergency-only bandwidth, local processing capable of initiating a help request independent of fleet management systems, and pre-defined emergency protocols that don't require cloud confirmation to execute.
The third gap is in contingency planning at scale. Traffic police in Wuhan handled the situation with impressive speed given the circumstances — but doing so required deploying officers to dozens of scattered vehicles simultaneously, coordinating with Apollo Go staff, and manually directing traffic around frozen cars in multiple locations across the city. That is not a scalable or repeatable emergency response model for a fleet that Baidu intends to expand by orders of magnitude. As Tech Brew observed in its post-incident analysis, there does not appear to be a widely adopted plan — in China or elsewhere — for what happens when a city's worth of robotaxis goes dark simultaneously.
The pace of autonomous vehicle deployment in China and globally shows no signs of slowing. Apollo Go will resume full operations in Wuhan. New cities will come online. The question is whether the industry will use this incident to close the gaps the Wuhan night exposed — or wait until the next failure is larger, in a city less prepared, with consequences harder to contain.
