829 Waymos drove inside the area San Francisco's December 2025 blackout hit. By Waymo's own filings, the cars handled dark signals for hours; what backed up was the queue of confirmation requests to a small human desk, all at once.
At about 1:04 on the afternoon of Saturday, 20 December 2025, an arc flash and fire broke out in a switchgear cubicle at PG&E's Mission Substation, at Eighth and Mission. The outage that followed reached "more than 120,000 customers at its peak," according to the engineering firm PG&E hired to investigate it, and the San Francisco County Transportation Authority put the loss at "roughly 30% of San Francisco." Traffic signals went out with everything else. Police had to manage intersections by hand, and the city's Department of Emergency Management advised residents to stay home.
Between noon and 11 p.m. that day, 829 Waymo robotaxis drove at some point inside the area the outage hit, by the company's own count to the California Public Utilities Commission. For the first few hours, Waymo says, its cars "were not encountering notable issues navigating darkened signals." Then, at about five o'clock, they began asking for help faster than it could be given.
Most of what followed is on the public record, in Waymo's own statements, in the city's filings and hearing notes, and in PG&E's engineering report. Read together, they show where Waymo itself located the problem. The cars handled dark signals on their own for hours. What backed up was the step where a car stops and asks a person for confirmation, once enough cars were asking at the same time.
Waymo's account of the outage, posted three days later, describes the rule: "While the Waymo Driver is designed to handle dark traffic signals as four-way stops, it may occasionally request a confirmation check to ensure it makes the safest choice." Its response to the CPUC in January says what the car does while it waits. Because the cars are built to handle the uncertainty cautiously, "they wait until their requests are addressed by RA agents," the Remote Assistance staff, "which usually happens promptly."
That afternoon it stopped happening promptly. In the filing's words: "At approximately 5 PM on December 20th, the volume of confirmation requests began to markedly exceed typical request volume, resulting in RA response times that were longer than typical. In a subset of cases, Waymo AVs waiting on confirmation from RA remained stationary at intersections with darkened traffic signals." At about 5:55 p.m. Waymo suspended ride-hail service and sped up bringing cars in. It had already started sending some back earlier in the afternoon, for a reason that belongs in this story too: "Waymo had already begun to return cars to the depot earlier in the afternoon, at approximately 3 PM, due to power outages experienced at Waymo facilities." The outage that darkened the signals had reached the operator's own buildings.
One number from the blog post needs careful reading. That Saturday, it says, "we successfully traversed more than 7,000 dark signals." That figure counts signals crossed. It does not count requests. Waymo has not published how many confirmation checks its cars sent that day, in the blog post or in its filing, and a party in the CPUC proceeding listed that number among the ones the company left out.
The city's account is harsher. The transportation authority's summary of a March hearing says the fire left "over 1500 Waymo robotaxis stalled at darkened intersections or in traffic lanes, eventually leading the company to suspend service. In at least 63 instances, Waymo AVs had to be manually retrieved, with San Francisco first responders directly handling at least two vehicle removals."
The 1,500 reads as a count of cars, but Waymo told the commission that 829 of its vehicles were in the outage area. The figure matches a different number in the same filing: stops of 120 seconds or more in which a car could not proceed without outside help, a "stoppage event" in the commission's definition. "Waymo's fleet logged 1,593 such stops in the affected area, over 96% of which were resolved by the vehicles continuing on their way, driving fully autonomously. The remaining stoppages were resolved by manual retrieval." Waymo adds that the stops "were not all related to traversals of intersections with darkened traffic lights," and that the total may include stops caused by other drivers and by ordinary congestion.
Waymo's blog post also puts the gridlock on the outage itself: "The scale of the outage and the sheer number of disabled traffic lights were the primary contributors to city-wide gridlock." Both accounts can hold at once. Waymo's cars did not darken the signals, and a car stopped in a lane still blocks whoever is behind it.
The cars were not the only ones waiting. The San Francisco Municipal Transportation Agency's reply comments to the CPUC, filed on behalf of the city's emergency management, fire and police departments, describe the calls going the other way. Between roughly 3 and 8 p.m., "numerous dispatchers placed a total of 31 calls to the Waymo first responder hotline for a total of two hours and thirty-six minutes of call time." The city says "a large majority of this time was spent on hold," and "one SFDEM staff person remained on the Waymo first responder hotline for 53 minutes."
The same filing lists three incidents in which, by the fire department's dispatch records, a Waymo got in the way of its crews. The earliest came at 2:20 p.m.: by the city's account, the fire department's initial response unit at the substation encountered a Waymo blocking traffic, hours before the surge in requests that Waymo describes. The fire department was having a surge of its own, with 801 calls in the 24 hours from 8 a.m. that Saturday against a daily average of 507. The second incident involved an ambulance. "An ambulance was dispatched to a location near the intersection of Natoma Street and 7th Street at 5:14 p.m. and was stopped en route by a disabled Waymo AV. Staff first called the Waymo hotline at 5:28 p.m. and requested relocation of the AV. Staff called again seeking an ETA for a Waymo field team at 5:55 p.m. The ambulance arrival was delayed by 40 minutes." The third was a working fire near Saint Louis Alley and Grant Avenue, where firefighters were dispatched at 5:32 p.m. A second unit heading there was blocked by a Waymo. Dispatchers called Waymo's line at 5:43 p.m. to have it moved, and at 5:53 one of them was still on hold.
At the March hearing, according to the transportation authority, Waymo "cited a surge in remote assistance requests during the blackout that delayed response times and first responder hotline answers." The same surge slowed both queues, the one the cars were in and the one the city's dispatchers were in. The record does not say why the ambulance's Waymo was stopped, so it cannot be pinned on the confirmation queue. It says the car was there, and that moving it depended on the same hotline the dispatchers were waiting on.
Waymo described the answering side in February, in a post by Ryan McNamara, its vice president and global head of operations. Remote Assistance, he wrote, "does not continuously monitor a vehicle or set of vehicles. Instead, they respond to specific requests for information initiated by the Waymo Driver." Then he gave a number: "As of February 17, 2026, there are approximately 70 Remote Assistance agents on duty worldwide at any given time, including ERT. For context, Waymo currently has a fleet of 3,000 vehicles." ERT is the Event Response Team, based only in the U.S., which "is certified for more complex tasks like coordinating with emergency responders and managing post-collision protocols."
Two cautions apply. The figure was published two months after the blackout, so it describes the operation after whatever Waymo changed. And it is worldwide, so it says nothing about how many of those people were free for San Francisco's cars, or its dispatchers, on the evening of 20 December. The supervisors asked a version of that question at the March hearing and did not get an answer. Company representatives, the authority's account says, "declined to disclose key details of interest to Supervisors when questioned, including how long disabled vehicles obstructed traffic, the ratio of remote operators to total operating fleet size, and when Waymo's operational capacity would be increased to ensure better response times."
What the February figure does show is the shape of the design. A small team answers questions that cars raise one at a time, across a fleet of thousands. The connection is fast: McNamara puts median one-way latency at about 150 milliseconds for U.S.-based operations centers. A queue adds its delay before anyone reads the request.
That shape is ordinary. Call centers and IT help desks staff for exceptions the same way, and it works for a reason: on a normal day, exceptions are independent of one another. One car meets a double-parked truck, another meets a construction crew across town, a third meets a confused pedestrian in another city, and the requests arrive as a scattered stream with a fairly steady average. Pool them, and a small desk keeps up, because a burst in one place is offset by quiet everywhere else.
A power cut takes that independence away. Every dark signal in the outage area puts the same situation in front of every car that reaches it, and the cars reach those signals in the same part of one city over the same few hours. A load like that has one cause, and every car inside the dark area meets it. Waymo's filing does not say what changed at five o'clock, about four hours after the substation failed. Whatever it was, a correlated load can build for hours below what the desk can clear and then cross that line, and once it does, every car in the queue sits where it stopped.
Waymo's December post reads the same way: "We established these confirmation protocols out of an abundance of caution during our early deployment, and we are now refining them to match our current scale. While this strategy was effective during smaller outages, we are now implementing fleet-wide updates that provide the Driver with specific power outage context, allowing it to navigate more decisively."
Two details in that paragraph matter. The protocol worked in smaller outages, which is what a design whose weak point is correlation would do: a small outage produces a small correlated spike, the desk absorbs it, and the test passes. A small outage gives no warning about a large one. And the first fix Waymo chose cuts the number of questions instead of answering more of them. A car that knows it is inside a known outage does not need a second opinion at every dark signal. At the hearing, Waymo added two more changes: "increased training for emergency hotline dispatchers, and creating a triage-type of system for prioritizing operational issues." Triage decides which questions get answered first, and training improves the people answering. Neither, as described, says how many people that is.
PG&E's investigators were looking at a different machine. Exponent, the engineering firm PG&E retained, produced a direct-cause evaluation dated 5 May 2026. Its finding: "The most likely direct cause of the arc-flash event within the Incident Cubicle is surface breakdown of the Incident Insulating Board," a panel the breaker's arms pass through. The most likely mechanism, Exponent says, is degradation of the board's surface where the arms could touch the edges of its holes, "likely assisted by moisture and surface contamination."
That board had been looked at almost seven weeks earlier. On 2 November, the breaker then in the cubicle "reportedly failed the high pot test," a high-voltage check, during its scheduled service. The damage reported in the cubicle was classed as "Minor": debris, surface rust, and "burned spots" and "warping" of the insulation board. Crews replaced the breaker with a spare and, by PG&E's account, cleaned the cubicle, wiping down the board's front. "The Incident Insulating Board was not reportedly removed, and consequently the CT-facing side (back) was neither inspected nor cleaned."
The cubicle had a defense against moisture: a space heater, there "to mitigate the relative humidity content within the cubicle." It was probably off. In the report's words, "the cubicle's heater was configured to be energized when both breakers in the cell were in the open position, while only one of the breakers in the cell (Incident Breaker No. 52) was in the open position at the time of the arc-flash event." The weather, meanwhile, had set up the case the heater existed for. Condensation forms when cold equipment meets warm, wet air, and after almost two weeks of cool weather, warmer temperatures and rain arrived on 17 December. "This is exactly the weather pattern that preceded the arc-flash event," the report says.
The building is ventilated with unconditioned outside air, drawn through a filter bank by basement supply fans. Exponent found the filters "compromised by water" and "the four supply fans were non-operational and air was being drawn through them, presumably by the rooftop exhaust fans." Broken belts on all four fans were documented at station inspections in December 2023, August 2024 and October 2024, and the repair "was not completed until January 2026, after the arc-flash event and after the out-of-compliance date of the notification."
The report is careful about what this proves, and the comparison has to be just as careful. How long the filters had been in that state, and how much the unfiltered air contributed, "are unknown." The document is a direct-cause evaluation only: "The root cause evaluation in this matter is ongoing." It does not say the broken fans caused the fire. It also records that the switchgear's own upkeep was largely on time: reviewing the maintenance notifications for every 12 kV breaker at the station, Exponent found that "Over 99% of PR notifications were completed by the compliance deadlines."
The comparison makes no causal claim in either direction, and one of the two investigations is unfinished. The two accounts still share a structure. In both, the main machinery has a decent record: breakers serviced on schedule, more than 7,000 dark signals crossed. In both, a protection was set for the conditions its designers expected, a heater that ran when both breakers were open and a confirmation protocol set "during our early deployment." And in both, the slack had gone out of a supporting system: the fans that kept the switchgear room's air moving, and the people who answer when a car, or a dispatcher, asks.
The city has already said the general version. Its CPUC reply asks for emergency plans whose requirements "should scale proportionally with fleet size and service footprint, recognizing that systemic risk increases as vehicle volume increases." That is the correlated-load problem in a city agency's words: the more units share a cause, the bigger the day when the cause arrives.
Any operator running many machines against a shared support function can run the check. Start with the causes that could hit many units at once: a power cut, a network outage, a storm, a bad software release, a holiday surge. For each one, ask how many units it would send to the same desk at the same time, and whether that desk, its hotline, or the field teams behind it could clear the queue before the waiting itself did harm. Where they could not, there are two ways out. Give the units enough context to handle the common case without asking, which is the fix Waymo says it is rolling out, or staff the desk for the correlated day instead of the average one. The third way out is the one Waymo used on the night, pausing the service and bringing the cars home. It works, but it is decided in the middle of the event, when the cars are already in the lanes.
The substation adds a smaller check: know which conditions switch your protections off. Cubicle 1112/12's heater was wired to run only when both breakers in its cell were open. On 20 December, one of them was not.
Two records would show how far the comparison really goes. PG&E's root-cause findings are still to come; Exponent says they "will be provided at the conclusion of the root cause investigation." The other is a set of numbers Waymo has not published: how many confirmation checks its cars sent that afternoon, how long they waited, and how many people were on duty to answer them. The February figure, about 70 agents worldwide at any given time, describes an ordinary moment two months later.
Sources
How this was checked. Every quotation above was checked word for word against the saved text of the source named beside it. No statistic in this piece is computed: every number is quoted from the source named beside it, and the only arithmetic is elapsed time between dates and times the sources give. Page numbers are the printed page numbers of each document.
Chain of Consciousness keeps a tamper-evident, dated record in hash-linked entries, so how many requests an automated system sent, and how long each one waited, can be checked later instead of reconstructed after someone asks.
pip install chain-of-consciousness npm install chain-of-consciousness
Or start without installing anything: Hosted Chain of Consciousness.