NYC Council meetings, chaptered and linked by time.
Independent project. Not affiliated with the New York City Council.
Created by Uzair Qadir
Inspired by Vikram Oberoi's City Meetings
New York City Council
Oversight - Examining New York City’s 911 Emergency System Outage
Read summaries and jump into the video at the segment start.
Council staff welcomes attendees to the joint hearing of the Committees on Technology, Fire and Emergency Management, Public Safety, and Governmental Operations. Instructions are given regarding cell phones, approaching the dais, and filing appearance cards to testify.
Chair De La Rosa frames the hearing around the FDNY EMS Local 2507 reminder that clinical death begins after four minutes. She describes the August 18 outage where Bronx PSAC 2 call takers could not hear callers for approximately seven hours, affecting about 1,700 calls, with as many as 400 callers never connected. She attributes the cause to a Motorola Solutions software update.
De La Rosa notes this was not an isolated incident, citing three Fire CAD outages and three EMS CAD outages in 2022, a human error disruption that October, and 2025 staffing shortages causing 911 callers to hear recorded hold messages. She emphasizes 911 is not an ordinary computer system.
De La Rosa states the hearing aims to learn what happened, why the public was not informed, what safeguards existed and failed, and what redundancy, testing, staffing, and accountability are needed. She welcomes testimony from FDNY, NYPD, OTI, advocates, and experts.
De La Rosa thanks Technology Committee staff including Legislative Counsel Irene Bohovsky, Policy Analyst Eric Brown, Chief of Staff James Burke, and others. She recognizes Council Member Gutiérrez and notes no other members have arrived yet before passing to co-chairs.
Chair Ariola of the Fire and Emergency Management Committee thanks co-chairs and describes the August outage as highly alarming. She outlines the hearing's focus on how FDNY and EMS dispatch systems were impacted, total number of affected emergencies, and training for personnel to handle disruptions.
Ariola acknowledges the approaching 25th anniversary of 9/11, thanking first responders who ran to ground zero and offering condolences for lives lost across agencies and the public. She passes to Chair Feliz.
Chair Feliz of the Public Safety Committee recognizes committee members and emphasizes that public safety is a core government responsibility. He notes New Yorkers rely on 911 during the most urgent and vulnerable moments of their lives and expect calls to be answered without delay.
Feliz describes the outage as starting at 3 a.m. and blocking calls for seven hours. He demands answers on what went wrong, why the update wasn't tested, why backup systems failed, and why the public was only notified seven hours later through the media rather than directly by the city.
Feliz notes the 911 system has had multiple outages: September 2024 due to a reconfiguration error, and 2022 when someone mistakenly pressed the power off button. He calls for ensuring the 911 system is safe from disruption and thanks agency staff and his committee team.
Chair Brewer of Governmental Operations asks why calls were not rerouted to the Brooklyn PSAC 1 facility, noting PSAC 1 and PSAC 2 are supposed to work together. She questions why it took so long to restore service and why the mayor failed to immediately inform the public, noting she learned about it from the press and local precincts.
Brewer, former Technology Committee chair, notes OTI's reliance on private companies for tech issues and wants to know how the Motorola partnership worked or failed. She thanks Government Operations Committee staff and her office staff, and recognizes Council Members Morano and Zhuang.
De La Rosa introduces the panel: CTO Lisa Gelobter, OTI Deputy Commissioner Robert Barbera, FDNY Deputy Commissioner Charles Jackson, NYPD Chief of Staff Ryan Marola, Assistant Chief Richard Napolitano, and Executive Director Elizabeth Matamoros. She also recognizes additional council members who have arrived.
Council staff asks all witnesses to raise their right hands and affirm to tell the truth and respond honestly to council member questions. All witnesses affirm. Staff announces Council Member Hanks is on Zoom and invites testimony to begin.
Gelobter introduces herself and her colleagues. She describes the 911 system as the largest in the country, receiving over 9 million calls annually. The PSACs are governed cooperatively by OTI, NYPD, and FDNY with a shared mission of uninterrupted emergency operations. She notes the outage occurred on August 18, 2026.
Gelobter explains the 911 core services infrastructure is a managed service by Motorola Solutions, handling hardware and software that receives, routes, and delivers calls. She describes two physical locations—PSAC 1 in Brooklyn and PSAC 2 in the Bronx—each equipped to independently handle the full daily load of about 25,000 calls.
Gelobter details the overnight upgrade: Motorola performed a routine firewall firmware upgrade at PSAC 2. The change process began at 9:45 p.m. on August 17 and completed at 4:13 a.m. on August 18. At that time, the upgrade was believed successful with all systems operational.
Gelobter reports the first problem indication came just before 6 a.m. when a call taker told their supervisor they struggled to hear alarm company calls. A tech support ticket was opened at 6:40 a.m., initially appearing as an issue specific to two adjacent call taker positions, typical of headset jack problems.
Gelobter describes how at 7:30 a.m. teams noticed increased alarm company calls, escalating to Motorola and Verizon. At 8:30 a.m. FDNY reported alarm calls not going through to NYPD. An operational bridge was opened at 8:45 a.m. including Motorola, OTI, NYPD, and FDNY for interagency coordination.
Gelobter explains the bridge team identified that 911 calls—not just alarm company calls—were affected. By listening to call recordings, they determined callers couldn't hear 911 call takers and traced the issue start to 3:13 a.m. By 9:50 a.m., they diagnosed the issue affected PSAC 2 routers while PSAC 1 routers were functional.
Gelobter reports Motorola began remediating by directing all call traffic to PSAC 1, incrementally disabling PSAC 2 trunks. At 10:19 a.m., all calls were successfully rerouted and services functioned normally. Call takers at both PSAC 1 and PSAC 2 continued handling calls throughout.
Gelobter provides preliminary impact data: 5,489 total calls during the outage, 70% successfully handled. Of 1,696 calls with issues, 742 were 911 calls from 319 unique phone numbers. 206 of those callers eventually connected; 113 unique callers were not serviced. Full root cause analysis is ongoing.
Gelobter outlines steps taken: PSAC 2 restored to working state by August 19, manual sampling of 911 call recordings, increased oversight, a freeze state on new deployments, and daily executive-level status meetings. Critical updates follow an exception protocol requiring executive review from all partner agencies.
Gelobter acknowledges ongoing work streams for fact-finding, analysis, and process improvements. She notes some questions may not yet have answers but commits to being clear and transparent about what is known. She welcomes the council's questions.
De La Rosa presses Gelobter on the gap between the issue starting at 3:13 a.m. and the upgrade completing at 4:13 a.m. Gelobter explains the issue wasn't caught until 9:30 a.m. and acknowledges it should have been caught earlier, with a deep dive underway to understand why and what alerts can be added.
De La Rosa asks if alarm company calls at 7:30 a.m. were what rang the alarm. Gelobter clarifies notifications came through multiple channels starting at 6 a.m., but it wasn't until 8:30 a.m. that the issues were understood as related, and 9:30 a.m. before 911 call impact was confirmed.
De La Rosa asks what process existed for detecting system failures and whether manual monitoring occurs. Gelobter confirms multiple electronic monitoring systems exist but did not catch this issue, and acknowledges the need to explore why and what additional safeguards can be implemented.
De La Rosa asks about Motorola's responsibilities. Gelobter says it's premature to ascribe specific responsibility during the ongoing investigation, but confirms Motorola's upgrade triggered the issue and they were not aware it broke. She notes the system was not prioritized by the previous administration.
De La Rosa asks who approves necessary updates and what the process is. Gelobter explains a Change Advisory Board (CAB) reviews changes, but this firmware upgrade was deemed low risk by Motorola and therefore did not require executive sign-off. She acknowledges this process needs revisiting.
De La Rosa asks if the low-risk flag is being reconsidered. Gelobter confirms they are examining risk assessment factors including production vs. lab environment, call rerouting needs, and whether callers or call takers would notice changes. She says they don't yet have answers but are looking thoroughly.
De La Rosa raises the 911 operator staffing shortage, referencing prior labor hearings about calls going to voicemail. NYPD Chief of Staff Ryan Marola reports 1,370 PCTs this year vs. 1,250 last year, with 400 PCTs added and total headcount up 5%. A class of 80 is in session and 100 more hires are planned for October.
De La Rosa asks about forced overtime, recalling testimony about an operator with an open ACS case due to inability to pick up their child. Marola reports 330,000 overtime hours year-to-date, about 32 hours per month per PCT, and projects voluntary-only overtime within 3-6 months. He commits to using common sense for personal emergencies.
De La Rosa asks for a NextGen 911 update, noting it has been in the works across three administrations. Gelobter says the current completion date is Q3 2027, having inherited a program the prior administration did not prioritize. She commits to a disciplined review of the schedule and safe, secure rollout.
Feliz disputes the framing that the outage was learned at 9:30 a.m., noting tickets existed at 6:40 a.m. Gelobter clarifies the 6:40 a.m. ticket was about alarm company calls, not 911 calls. Feliz argues alarm calls are effectively emergency calls, making the 9:30 a.m. framing inaccurate.
Feliz asks what steps were taken after alarm call problems surfaced and why a broader look wasn't taken sooner. Gelobter explains reports came from different channels with different contexts—first investigated as headset issues, then alarm routing with Verizon, then the broader bridge call at 8:30 a.m.
Feliz asks how many alarm calls had issues before the first ticket. Gelobter doesn't have the specific number but notes about 1,000 alarm calls were affected during the entire disruption period. She explains alarm calls use auto-dialers that repeat until connected, which may explain the volume increase noticed.
Feliz asks when each agency was notified. Gelobter says NYPD call takers at 6 a.m. were the first to notify OTI. FDNY was invited to join the operational bridge call starting at 8:54 a.m. The mayor was informed through the deputy mayor of operations and first deputy mayor during the day.
Feliz asks what systems exist to detect whether the call system is online, noting a seven-hour outage without awareness is concerning. Gelobter confirms monitoring exists at multiple levels but did not catch this issue. Feliz expresses alarm that the city might not know if an outage or cyberattack is occurring at any given moment.
Feliz asks about past outages. FDNY Deputy Commissioner Charles Jackson explains the 2021 FireCAD launch had initial hiccups but is now stable, and EMS CAD is being replaced with a November 2027 target. The 2022 EPO button incident involved a contractor pressing emergency power-off buttons, causing a 15-minute EMS CAD outage; countermeasures including button covers and vendor restrictions were implemented.
Feliz asks about the September 2024 seven-hour Bronx outage. Deputy Commissioner Barbera explains it was a Verizon configuration error during E911-to-NextGen 911 migration, impacting a small number of calls on a particular route to PSAC 2. The issue was on the carrier side, not within city systems.
Feliz asks if OTI planned to notify the public and when. Gelobter explains there was a 45-minute window between learning 911 calls were affected (9:30 a.m.) and remediation (10:19 a.m.), with 70% of calls still successful. She says the focus was on fixing the issue, and public notification might have deterred people from calling 911.
Feliz challenges the framing that the issue was only learned at 9:30 a.m., arguing alarm call issues at 6:40 a.m. warranted public notification. He states that when calls aren't going through, the public should be notified immediately so they can seek alternative help. Gelobter acknowledges communication procedures need revisiting.
Feliz asks if it makes sense to inform the public about outages. Gelobter agrees they must revisit communication procedures internally and externally, including when the public should be notified and the criteria for that decision.
Feliz asks if this is the first outage this year. Gelobter reveals a text-to-911 outage in May lasting about 110 minutes, affecting 12 texters who received bounce-back messages instructing them to call. Feliz expresses outrage that this two-hour outage was also kept secret from the public.
Feliz demands to know why the May outage wasn't publicized, noting people text 911 because they're in imminent danger. Gelobter explains texters received bounce-back messages directing them to call, which served as notification of an alternate method. Feliz argues outages shouldn't be kept secret.
Council Member Sanchez asks about reports of mismanagement and too many players involved. Gelobter explains the PSAC steering committee comprises NYPD, FDNY, OTI, with DCAS, OMB, and Cyber Command also participating. She agrees the governance structure, processes, and policies need closer examination.
Sanchez asks about other outages beyond August and May. Gelobter says she doesn't believe there were other New Yorker-facing disruptions in 2026, but acknowledges technology issues occur regularly and the team's job is to remediate them quickly before New Yorkers are affected.
Sanchez states outages shouldn't be kept secret, arguing the public should have been notified by 6:40 a.m. on August 18 so people could seek alternative help. He calls keeping outages hidden unacceptable and not how good government works. Gelobter says they will look at public notification policies.
Ariola walks through the timeline, questioning the 40-minute gap between the 6 a.m. problem and the 6:40 a.m. ticket, and asking who is responsible for diagnostics—OTI or Motorola. She also asks how long in advance OTI knew about the update and whether partner agencies were notified.
Ariola asks whether NYPD, EMS, and FDNY were notified about the update. Barbera confirms changes go through the Change Advisory Board with all agencies. Gelobter clarifies this was assessed as low risk and did not require executive-level approval from all agencies, which Ariola questions.
Ariola asks when OTI was notified about the update. Barbera says they were notified in February, with testing in March and subsequent months. Ariola asks about the low-risk threshold; Gelobter says the definition was set by Motorola and will be revisited. Ariola asks why Motorola is not at the hearing.
Ariola asks why Motorola isn't present and whose responsibility it was to notify OTI. Gelobter says the root cause analysis is ongoing and it's premature to ascribe responsibility, but confirms Motorola performed the firmware upgrade that caused the issue and the first notification came from call takers, not Motorola.
Ariola asks about the protocol for OTI telling NYPD and FDNY when something goes wrong. Gelobter reiterates that in this case NYPD notified OTI. Ariola calls it embarrassing that OTI heard from sister agencies, asking why OTI didn't have supervisors on site checking systems.
Ariola asks what 'eventually connected' means for the 206 of 319 callers. Gelobter says some called back and were routed via PSAC 1, and NYPD called back others. Marola details that NYPD made 526 callbacks in 24 hours, reaching 32 individuals who no longer needed emergency services. Ariola presses on the timeline of 'eventually.'
Ariola asks how OTI described the impact in outage notifications and whether NYPD receives routine notifications. Gelobter says notifications went out per normal process for the release. Ariola questions why NYPD receives notifications for smaller maintenance but wasn't notified beforehand about this update, and why OTI learned from NYPD.
Ariola asks why the public wasn't notified for seven hours when Notify NYC could have been used with the click of a button. Gelobter says there were 45 minutes where they knew New Yorkers were affected, 70% of calls were still going through, and the focus was on remediation. Ariola insists public communication should have been immediate.
Ariola reframes the 45 minutes as time when New Yorkers were in jeopardy. Gelobter says the primary focus was addressing the issue quickly and 70% of calls were successful. Ariola states the scope of a 911 system outage is always critical and public information should have been sent out immediately.
Ariola notes the mayor attributed the disruption to Motorola's software update and asks whether Motorola should be present to explain. Gelobter says until the root cause analysis is complete, they don't know who needs to be in the room. Ariola asks if the maintenance was routine, scheduled, and approved—Gelobter and Barbera confirm it was.
Ariola cites a New York Times report at 9:24 a.m. that stated no impact to 911. Gelobter clarifies that at 9:24 a.m. the notification was about alarm calls being impacted, and they didn't learn 911 calls were affected until later. A second notification between 10:20 and 11 a.m. confirmed alarm issues resolved and no 911 impact at that point.
Ariola asks if NYPD was actively working with Motorola during the outage. Gelobter confirms all agencies and vendors were on the bridge call starting at 8:54 a.m. Ariola then asks when FDNY was notified—Gelobter says they were part of the bridge call distribution list notifications.
Ariola presses on when FDNY was absolutely made aware. Gelobter explains the standard protocol of sending bridge call notifications to distribution lists including PD and FD. Ariola notes both responding agencies had to notify OTI about the outage, which she finds unacceptable.
Ariola emphasizes that both FDNY and NYPD—the agencies responsible for public safety—had to notify OTI about the breakdown, and OTI still didn't think the public needed to be made aware. She calls the seven-hour gap and lack of public notification egregious, reserving the right for a second round.
Brewer asks if NYPD will honor the call taker who first reported the problem. Marola confirms they plan to give the call taker and the principal who escalated it a commander's day—a free day off. Brewer then asks about redundancy between Brooklyn and Bronx PSACs.
Brewer asks why redundancy between PSAC 1 and PSAC 2 didn't work. Gelobter explains redundant systems exist for cybersecurity breaches, power outages, and natural disasters, but this issue didn't trigger any fail-safes. She acknowledges the need to understand what additional alerts can be put in place.
Brewer asks if a subcontractor performed the low-level changeover or if Motorola did it themselves. Barbera confirms the work was performed by Motorola directly. Brewer then asks about NextGen 911 benefits.
Brewer asks what NextGen 911 will do differently. Gelobter explains E911 is legacy and analog, while NextGen 911 introduces digital systems that should streamline processes, improve logging, tracking, analysis, and alerting. Phase one rollout is the priority before additional modern features.
Brewer raises concerns about training for low-level upgrades and whether city agencies get adequate knowledge from outside contractors. Gelobter acknowledges the managed service model means OTI doesn't have hands on the wheel but says they need to look at oversight, approvals, and change management. She notes pros and cons of the managed service approach.
Brewer asks about Verizon's role. Barbera explains the city is in a hybrid state between E911 and NextGen 911: Verizon is the primary E911 provider, Motorola is the primary NextGen vendor. Once migration completes, E911 will be decommissioned and Verizon's role reduced to communication services.
Brewer asks who was tasked with detecting the issue, noting the call taker did the right thing but questioning whether Motorola should have caught it. Gelobter says Motorola was not aware the upgrade broke, and it shouldn't depend on hitting an end user before anyone is alerted. She calls this a key area for the root cause analysis.
De La Rosa recognizes Majority Leader Abreu, Council Members Banks and Salam on Zoom, and announces the first round will start with Wong, Morano, and Hanif. She also recognizes Council Members Riley and Won who have arrived.
Council Member Won asks how often firmware updates happen and whether the city tests them. Barbera confirms hundreds of updates happen per year, with test protocols before, during, and after changes. Won presses that testing failed to catch the issue. Barbera explains the issue surfaced an hour after the change completed, during a period when validation showed successful calls.
Won questions why there isn't a backup PSAC 2 system that can be switched on when the primary fails, and whether rerouting all traffic to PSAC 1 would overload it. Gelobter explains each PSAC can independently handle the full city load. Won argues for a disaster recovery backup with original configurations ready to switch on.
Won presses on why the system wasn't switched to backup sooner. Gelobter explains 70% of calls were being handled, making the issue appear intermittent, and they didn't know PSAC 2 routers were the problem until 9:50 a.m. She acknowledges the need for better topology and redundancy going forward.
Council Member Morano focuses on the human impact, noting that if someone is having a heart attack, they don't care about software. He asks how 911 calls began failing at 3:13 a.m. without the city knowing, what automated monitoring should have caught it, and why the first effective alarm was a call taker saying 'I can't hear somebody.'
Morano asks if the city has identified what emergency each of the 113 unserviced callers was calling about and whether any suffered injury, death, or property loss. Gelobter says based on review to date, no death or injury attributable to the disruption has been identified, but the analysis is ongoing.
Morano asks if Motorola has faced any financial consequence—withheld payment, service credits, cure notice, or contractual remedy. Gelobter says it would be premature to ascribe blame before the root cause analysis is complete, but they will explore recourse after the analysis is finished.
Council Member Hanif asks what types of emergencies the unanswered 911 calls were for. NYPD reports 526 callbacks were made in 24 hours, reaching 32 individuals. The issues ranged from disputes to ambulance needs, none requiring additional emergency services at contact time. Nearly 500 callers never responded.
Hanif asks if there were attempts to check back after the 24-hour period. Marola explains OTI and the vendor spent weeks refining the list of numbers that didn't reach, as the initial list may not have been accurate. He confirms additional attempts were made beyond the first 24 hours.
Hanif asks whether 988 was affected and if mental health crisis callers were among those impacted. Chief Napolitano explains if someone called 988 and stayed with 988, there was no impact, but if 988 transferred to 911, it could have been affected. They don't have figures but will investigate.
Hanif asks about researching what other cities do for backup routing and independent entities outside the police department. She also asks how the city plans to address distrust in the 911 system. Gelobter commits to looking at alternative routes, learning from other cities, and restoring trust through the root cause analysis and NextGen 911 implementation.
Majority Leader Abreu asks about the May text-to-911 outage and what happened if affected individuals were deaf or hard of hearing. Barbera explains TTY was still available on voice services, and translation apps calling through national 911 were also available. Abreu asks about those who needed to be quiet for safety.
Abreu asks what happens if someone's safety requires them to be quiet and unable to make phone calls. Barbera explains the bounce-back message was activated to prevent people from believing help was coming when it wasn't. Abreu notes 12 individuals received the bounce-back message.
Abreu notes outages have happened at least twice this year and asks why there isn't a go-to policy for notifying the public. Gelobter says they are exploring policies and procedures including when and how New Yorkers get notified. Abreu presses on how fast an answer will come, fearing no procedure exists if an outage happens today. Gelobter says she's personally been in contact with NYSEM about Notify NYC.
Council Member Zhuang asks how many of the 400 affected people suffered harm and whether there is any compensation from the city or Motorola. Gelobter reiterates no death or injury has been identified, 206 of 319 callers eventually connected, and the investigation into the remaining 113 is ongoing. Zhuang asks for follow-up.
Council Member Stevens challenges Gelobter's references to the prior administration not prioritizing the system, asking what concrete steps this administration is taking differently. Gelobter outlines the root cause analysis examining technical architecture, testing, monitoring, vendor performance, and communications, but Stevens finds the answers too broad.
Stevens demands specifics on staffing changes, resource investments, and technology upgrades, asking for dollar amounts and deadlines. Gelobter says the root cause analysis must be completed before specific changes can be announced. Stevens presses for a deadline and calls the ambiguity alarming and unacceptable, saying it seems like information is being withheld from the council and public.
Council Member Maloney, citing her technology sector experience, asks why Motorola deemed the upgrade low risk and why OTI didn't push back. Barbera explains the low-risk designation was based on calls being rerouted during the change. Maloney urges reevaluating risk criteria and questions why the full rollout proceeded and why internal metrics didn't catch the error.
Maloney asks what role or liability Motorola has and what enforcement mechanisms exist. Gelobter says it's premature to ascribe specific responsibility before the root cause analysis. She confirms OTI manages the vendor, both OTI and Motorola track metrics, and the contract includes terms about contractor responsibilities and consequences for deficiencies.
Maloney asks who is responsible for tracking metrics and testing (both OTI and Motorola), who manages the vendor (OTI), and who communicates to the public during outages. Gelobter says NYSEM sends messages but the criteria and process for when they're notified need to be determined. Maloney asks who let NYSEM know and when—they became aware at 9:30 a.m. with 45 minutes of known impact.
Council Member Riley, representing the Bronx, asks why calls didn't automatically transfer from PSAC 2 to PSAC 1 when the router failed. Gelobter confirms the cutover does not happen automatically for this type of situation, which is something they need to address going forward.
Riley asks what backup systems exist if this happens again. Gelobter describes the fully redundant PSAC 1 and PSAC 2 architecture, additional redundancies she can't detail for security reasons, and interim measures including daily change management calls, deployment freeze, hourly manual call recording sampling, and PD call taker training on escalation.
Riley asks if there's data on how many affected calls were fire or medical emergencies. FDNY responds they only know about calls transferred to them and are analyzing a list from OTI of callers who had issues and called back. They confirm there were no active fires that day.
Riley notes he learned about the outage from a news reporter, not from the administration. He asks if there's a protocol to alert council members so they can help navigate calls. Gelobter appreciates the question and says they will explore notifying appropriate stakeholders as part of their protocol review, and Riley urges them to utilize council members as partners.
Council Member Restler expresses deep concern about the outage's public safety implications. He asks if OTI, NYPD, and FDNY are working together on better testing. Gelobter confirms the root cause analysis will address testing, monitoring, change management, and communications, with a current freeze state on non-critical updates.
Restler notes that while real-time communication during an outage may be sensitive, the failure to reach out to stakeholders afterward was alarming and felt like an effort to shove it under the rug. He asks for a commitment to meaningful post-incident communication. Gelobter commits to identifying stakeholders, criteria, and mechanisms for notification.
Restler asks if new protocols are in place for testing and redundancies during future upgrades. Gelobter says this is the crux of the root cause analysis—testing, monitoring, change management, and communications all need examination. She confirms the freeze state means only critical issues are being pushed.
Restler asks why the Bronx location was affected. Gelobter explains Motorola pushed firmware to PSAC 2 firewalls deliberately, as PSAC 2 gets less traffic than PSAC 1, and rolling out one center at a time ensures the other remains unaffected. Call takers at both centers handled calls throughout.
Restler uses the opportunity to argue that PSAC 1's location in downtown Brooklyn's MetroTech campus is wrong, saying it closes off core streets and prevents the campus from being vibrant. He suggests the eastern Bronx location makes more sense and calls for reconsidering the downtown Brooklyn site. He acknowledges no one will respond today but says he's starting the push.
Council Member Dinowitz asks about the May texting outage. Barbera explains it was caused by a larger system upgrade after six years live, and took 110 minutes to resolve because many components had to be reverted. Dinowitz asks how many minor outages occur; Gelobter says only the May and August incidents impacted New Yorkers in 2026.
Dinowitz asks about the NYPD's 6 a.m. notification. Elizabeth describes how a call taker experienced multiple calls with no audio from the same caller ID, and a neighboring call taker was told by a caller they couldn't get through to 911 and 311 transferred them. Approximately 10-11 calls were noticed before escalation.
Dinowitz asks for a ballpark of affected calls. Elizabeth reports 322 calls with one-way audio from the 10-digit alarm number between 3:13 a.m. and 6 a.m., presented to 83 unique call takers. It didn't feel out of the norm until one call taker received many in a row and raised the alarm.
Dinowitz asks what steps were taken. Gelobter explains teams looked at hardware, headsets, and position-specific issues. Barbera adds they triaged what was believed to be a looping alarm auto-dialer, engaged Verizon for alarm routing, and escalated when the broader scope became clear.
Dinowitz asks how often updates occur and whether this was major or minor. Barbera says it was minor, with updates almost daily—2,800 changes in 2025 without impact. Dinowitz asks how management can be improved. Gelobter says they're examining governance, risk assessment, technical processes, policies, and communications.
Dinowitz asks what systems exist to know if systems are online or if there's an outage. Gelobter confirms monitoring exists at different infrastructure levels but can't detail for security reasons. She adds interim manual measures including hourly call recording sampling and PD call taker training on dead air call escalation.
Morano asks who independently verifies Motorola's account, noting Motorola performed the change, diagnosed the problem, helped restore service, and is now analyzing the root cause of its own failure. He asks if any outside technical expert, comptroller, or inspector general is reviewing the evidence. Gelobter says she is personally overseeing it and they need to ensure Motorola delivers to required standards.
Morano asks how dependent the city is on Motorola and whether they could realistically replace them. Gelobter says Motorola plays a big role across multiple services but the city should never be tied to one vendor for life. She commits to ensuring Motorola delivers on contracts but doesn't say they could be replaced quickly.
Morano asks directly if the city could operate and maintain the system if Motorola stopped providing support. Gelobter says today, with NextGen 911 implementation ongoing, they could not turn that off and pick up the work without significant impact. Morano then asks who is the single city official ultimately accountable for 911 system integrity. Gelobter says that needs to be addressed, with OTI managing the Motorola contract specifically.
Council Member Won notes the original NextGen 911 completion date was 2018, slipping to 2024, 2025, and summer 2026. Gelobter confirms the current date is Q3 2027 and says as the new CTO she will take a hard look at the schedule given the delays. Won then asks about FDNY independent verification of EMS calls during the outage.
Won asks if FDNY has an independent verification system separate from OTI for EMS calls. FDNY responds they only see calls transferred to them and have no direct visibility into 911 intake. They asked OTI for a list of callers who had issues and called back, and are currently reviewing those calls. Won says this needs to be part of the emergency plan.
Council Member Felder asks whether the update was to software or hardware, noting both terms were used in testimony. Gelobter explains firewalls are physical hardware that run software/firmware, and this was a firmware update on the firewalls. Felder then asks about Verizon and T-Mobile's roles.
Felder asks about Verizon's role and articles mentioning T-Mobile as a 911 network provider. Barbera clarifies Verizon is the E911 provider for NYC, and T-Mobile does not play a role in 911 call delivery within the city's infrastructure, though they provide 911 service to their customers. NextGen 911 is primarily a Motorola managed network.
Felder asks about Motorola's liability under the contract for service interruptions, indemnification provisions, and warranty disclaimers. Gelobter says the contract includes terms about responsibilities, consequences, and deficiencies, but it would be irresponsible to comment on application before the root cause analysis is complete. Felder says they'll follow up with a letter.
Felder asks about NYC Cyber Command's current responsibility for 911 cybersecurity, referencing 2022 testimony. Barbera explains there's joint management between OTI's public safety team and Cyber Command. Gelobter adds Cyber Command has a seat on the PSAC steering committee and lives within OTI, responsible for ensuring vendors meet strict cybersecurity requirements.
Felder asks if OTI or Cyber Command has conducted cybersecurity audits, penetration testing, or vulnerability assessments of 911 systems. Barbera confirms continuous monitoring 24/7, with penetration testing and vulnerability assessments conducted on an ongoing basis as part of strict implementation requirements.
Felder asks what policies will govern access, retention, sharing, and deletion of photographs, videos, and text messages that NextGen 911 will accept. Gelobter says they need to circle back, noting the Office of Privacy lives within OTI. Barbera clarifies those functions are not in phase one but in the next phase, requiring legal assessment of retention requirements.
Felder asks about the status of predictive analysis initiatives to stage first responders based on anticipated 911 demand. Barbera says this is part of NextGen 911 Phase 2, which hasn't started yet. Gelobter says they need to revisit previous plans and ensure whatever is built is correct, safe, and secure before adding features.
Felder asks if the city has implemented, tested, or contracted for any AI-enabled Motorola functionality. Gelobter says Motorola's AI capabilities are dependent on NextGen 911, which hasn't rolled out yet. AI is not part of phase one, and they will explore what makes sense to add after NextGen is live.
Felder asks about an April 28 letter on data privacy, facial recognition, and biometric data governance that hasn't been answered. Gelobter says it's under review. Felder also asks about Local Law 188 of 2025 establishing the Office of Algorithmic Accountability; Gelobter says six lines were funded in the FY27 budget, hiring is underway, and analyses are due by end of March.
Felder asks about a call during the outage where a civilian couldn't reach 911 and was transferred from 311 to NYPD. NYPD confirms that at 6 a.m., in addition to calls with no audio, a call taker was informed by a caller (believed to be an alarm company) that they couldn't get through to 911 and called 311, which transferred them to 911—standard protocol.
Feliz asks what Motorola thinks about the outage—whether it was preventable or inevitable. Gelobter says they are in active conversations with Motorola to understand root causes and what can be remediated on both ends, but doesn't have specifics yet.
Feliz asks at what point the city determines whether a call issue is minor or systemic. Gelobter says every issue is taken seriously and looked at with all due haste, though diagnosing the source in a complex system can take time. Feliz also asks about the May outage detection time—Gelobter says it was detected within a few minutes.
Feliz thanks the panel from OTI, FDNY, and NYPD for their work and answers. He states the committee will send a follow-up letter for unanswered questions and looks forward to the root cause report and deeper exploration of NextGen 911. He emphasizes the urgency is about ensuring New Yorkers get help in their worst moments. The panel is dismissed and he thanks council members who stayed throughout.
De La Rosa reminds the public this is a formal government proceeding requiring decorum. She outlines rules: no video recording or photography from the witness table, no audio or video recordings as testimony, three minutes per speaker, and written testimony may be submitted to the sergeant at arms or emailed within 72 hours.
Rosenthal, Director of Advocacy at Community Access and leader of the Correct Crisis Intervention Today coalition, advocates for making NYC's 911 system fully independent of NYPD. He cites Seattle and Austin as cities that have done this, references University of Chicago expert Rebecca Neustrachter's research, and argues independence would improve crisis response and reduce harmful police deployments to mental health calls.
Blommenville, a former technology analyst and educator, speaks on behalf of Havana Syndrome victims, describing remote access to human biology, organized stalking, electronic assault from directed energy weapons, and non-consensual experimentation. She requests a Havana Syndrome Awareness Day, protocols for OTI and 311 participation, and a meeting to discuss resources for victims.
Longmanville, a retired Chase Manhattan Bank technology analyst who worked on Y2K compliance, describes being experimented on with various technologies and tortured 24/7 at the mercy of whoever has access to her biometrics. She asks for advocacy and support to protect her rights.
De La Rosa thanks everyone for attending, acknowledges Chairs Feliz, Ariola, and Brewer for their collaboration and leadership, and says the council looks forward to continuing to dig into these issues. She adjourns the hearing.