On the morning of August 18, New Yorkers who dialed 911 through the Bronx call center reached a call taker who could not hear them. It lasted seven hours. On September 9, four City Council committees spent three hours asking the NYC Office of Technology and Innovation (OTI), the NYPD, and the FDNY how that happened. We watched the whole thing. Here is what we took away, and one thing we are asking the city to do.
TL;DR: A vendor firmware update left Bronx 911 call takers unable to hear callers for seven hours on August 18. No monitor caught it, the public was never told, and 113 callers never got through. NextGen 911 has slipped to 2027. We are asking the city to publish a 911 outage dataset on NYC Open Data. Read our ask.
What broke
The city’s 911 core, the hardware and software that takes a call from a carrier and hands it to a call taker, is run for the city by Motorola Solutions as a managed service. Overnight on August 17, Motorola updated the firmware on the firewalls at the Bronx center, known as PSAC 2. The work ran from 9:45 PM to 4:13 AM. Tests ran and passed. OTI later traced the first failed calls to 3:13 AM, before the work was marked complete. Chair Carmen De La Rosa asked about that gap and did not get an explanation. What OTI did say is that the failure only surfaced once live sessions timed out, which the testing did not catch.
From 3:13 AM until 10:19 AM, callers routed through the Bronx could not be heard. Calls routed through Brooklyn were fine. About 70 percent of calls in that window went through normally, which is part of why it took so long to find.
By OTI’s count, 319 people called 911 and hit the problem. 206 got through later, by calling back or being called back. 113 never did. The city says it has found no death or injury tied to the outage. It also cannot yet say what those 113 people were calling about.
Who caught it
No alarm went off. Two NYPD call takers noticed a run of silent calls just before 6 AM and told their supervisor. The first guess was a bad headset. Then NYPD saw alarm-company auto-dialers redialing over and over. Then the FDNY started hearing from alarm companies that could not get through. It was 8:54 AM before everyone was on one call, 9:30 before anyone confirmed that 911 calls were affected, 9:50 before the Bronx routers were identified as the cause, and 10:19 before every trunk had been moved to Brooklyn by hand.
CTO Lisa Gelobter was direct about it: the monitoring did not catch this, and Motorola did not know it had broken anything. Council Member Joann Ariola put it more sharply. The agencies that answer the phones had to tell the agency that runs the phones.
The part that should worry you
Motorola rated its own change “low risk.” Under the city’s process, a low-risk change gets logged with the interagency change board but does not need executive sign-off from OTI, NYPD, and FDNY. OTI executed about 2,800 changes in that environment in 2025, and firmware updates happen hundreds of times a year. The risk question OTI described was whether calls would be affected while the work was happening. They were not, because traffic had been moved. The failure only appeared after traffic moved back and live sessions timed out.
So the vendor set the risk, the vendor did the work, the vendor did not notice the failure, and the vendor is writing its own analysis alongside the city’s. Asked who independently checks that analysis, Gelobter answered, “me,” and added that the vendor relationship needs a closer look. Asked whether Motorola has faced any financial consequence, the answer was no, not yet.
Nobody was told
There was no Notify NYC alert. No press statement while it was happening. At least two council members, one from the Bronx, said they learned about it from reporters. OTI’s position is that it knew 911 calls were affected for only 45 minutes, and it chose to spend that time fixing the problem rather than announcing it. Several members rejected that framing. The first tech-support ticket was filed at 6:40 AM. OTI says it described alarm-company calls; Chair Oswald Feliz argued that was reason enough to warn the public.
It was also not the first time this year. A text-to-911 outage in May lasted 110 minutes and was never announced. The city does not have a policy for when to tell the public that 911 is degraded. Gelobter said one is being worked out with NYC Emergency Management.
NextGen 911 slipped again
The Council had been told the city’s long-running 911 modernization would finish this summer. The new date is the third quarter of 2027, and Gelobter said she intends to take a hard look at even that. Photo, video, precise location, predictive analytics, and any AI features are not in the current phase, and the second phase has not started.
Also discovered: the algorithmic accountability office is hiring, not yet analyzing
Asked on behalf of Council Member Jennifer Gutiérrez about the Office of Algorithmic Accountability created by Local Law 188 of 2025, Gelobter said OTI has six positions funded in the FY27 budget, is still designing the office, and is recruiting. Its first analyses are due by the end of March. In the same stretch of questioning she said any AI or predictive features for 911 are years off, and the committee’s April letter on facial recognition and biometrics remains “under review” after four months.
Our ask: publish the outages
Every number in this post came from someone saying it out loud at a hearing. There is no public log of 911 outages. The May outage was never announced. It came out because a council member asked.
We think the city should publish a 911 outage dataset on NYC Open Data. Each row: when it started, when it ended, which centers and channels were affected, roughly how many calls, and the cause once it is known. We see no security case against it. Every field in that row was stated under oath at a public hearing. Publishing it just means the next one does not need a hearing to surface.
Ask your council member to write it into the follow-up letter the four chairs said they are sending.
How to send testimony to the Council
You do not have to attend a hearing to be on the record. The Council accepts written testimony for 72 hours after a hearing is adjourned, on any topic it heard. The rules are on the Council’s Hearing Testimony Registration page. For this hearing the window closes September 12.
Two ways to send it. Upload a file through the form on that page, in .doc, .rtf, .txt, or .pdf. Or email it to testimony@council.nyc.gov, which is the address Chair De La Rosa gave from the dais. Either way it goes into the public record, so include only the personal information you want made public.
A few things that make testimony land. Say who you are and, if it applies, what happened to you or someone you know on August 18. Name the hearing and the file number, T2026-2481. Make one clear ask. Keep it to a page. And send us a copy; we would like to know what New Yorkers are asking for.
If you missed the window, write to the committee chairs directly: Carmen De La Rosa (Technology), Oswald Feliz (Public Safety), Joann Ariola (Fire and Emergency Management), and Gale Brewer (Governmental Operations). Their office emails are on their Council pages.
For future hearings, the Council calendar is on legistar.council.nyc.gov. If you use an AI assistant that speaks the Model Context Protocol, our free, open-source nyc-council-mcp lets it search upcoming hearings, bills, votes, and council members straight from Legistar. You can also sign up on the testify page to speak live, in person or by Zoom. If you need ASL, CART, or interpretation, email EEOOfficer@council.nyc.gov or translationservice@council.nyc.gov at least three business days before the hearing.
We took our own advice. Here is the testimony we submitted on September 10, asking the Council to require a public 911 outage dataset.
How this post was made
We downloaded the hearing video from the Council’s website, ran it through an AI transcription service (Deepgram) to get a time-stamped, speaker-labeled transcript, and used Claude, an AI model from Anthropic, to draft this post from that transcript and to check the draft against it. We checked every council member’s name against the Legistar roster using our own nyc-council-mcp, the same tool linked above. A staff member reviewed every claim and edited the text. The AI did not decide what mattered or what we are asking for. If you find an error, tell us and we will fix it. Our full AI policy is at beta.nyc/about/ai-policy.
The hearing video and transcript are on Legistar. Council Members Carmen De La Rosa, Oswald Feliz, Joann Ariola, and Gale Brewer chaired.