From 911 Outage Notice to Call-Through Recovery Evidence
911 outage reporting in the United States has mature regulatory components: provider outage reports, PSAP notifications, reliability certifications, and new NG911 transition requirements. Those components are necessary, but they do not by themselves prove that callers got through, that fallback paths worked, that location data arrived, or that service was validated after restoration. This conceptual synthesis reviewed AlexandrAI graph results and 21 official, regulatory, incident-report, government, standards, and continuity sources from the FCC, eCFR, GAO, the National 911 Program, CISA, and NENA. It contributes a notice-to-call-through recovery chain that separates incident discovery, PSAP notification, situational assessment, fallback activation, call-through denominator, metadata integrity, restoration validation, and after-action repair. FCC incident reports from 2014, 2017, and 2018 show why the distinction matters: public outage duration and affected-population measures are weaker than evidence about attempted calls, failed deliveries, notification quality, alternate routing, and verified restoration. Public 911 outage reporting should therefore state the weakest verified stage instead of treating notice or restoration language as call-through recovery evidence.
Introduction
When a 911 outage occurs, the public question is practical: can a person who dials or texts for emergency help reach the correct call center with usable location and callback information? Regulatory reports, provider notices, network restoration announcements, and annual reliability certifications all matter, but each verifies a different part of the answer. A regulator can receive a timely outage report while residents are still unable to complete emergency calls. A public safety answering point (PSAP) can receive a notice while still lacking enough detail to warn the public. A network component can return to service while dependent routing, call handling, or location metadata remains uncertain.
FCC materials already recognize these distinctions. The Enforcement Bureau frames its 911 outage work around call completion from the caller to the appropriate PSAP, while the FCC's NORS and 911 reliability pages distinguish outage reporting, PSAP notification, and reliability certification duties [[cite:fccOutagePage,fccNors,fccReliability]]. Current Part 4 rules require outage reports and 911 special-facility notifications; Part 9 requires covered 911 service providers to certify reliability measures for circuit diversity, backup power, and network monitoring [[cite:ecfrPart4,ecfr919]]. These obligations are the backbone of accountability, but they are not the full evidence chain.
The gap is easiest to see in incident reports. In April 2014, a software coding error in a Colorado call-routing facility affected 81 PSAPs in seven states and prevented more than 6,600 911 calls from reaching a PSAP [[cite:fcc2014]]. In March 2017, nearly all AT&T Mobility Voice over LTE customers nationwide lost 911 service for five hours, and about 12,600 unique users attempted to call 911 without reaching emergency services through the traditional 911 network [[cite:attVolte]]. In December 2018, a CenturyLink network outage affected as many as 22 million customers and left about 17 million customers without reliable access to 911; at least 886 911 calls were not delivered [[cite:centurylink]]. In each case, the strongest public-relevant evidence is not merely that an outage happened. It is how many emergency calls failed, what fallback was available, and when the system was truly usable again.
This paper asks how 911 outage reporting should distinguish notice, notification, fallback, call delivery, metadata integrity, restoration, and repair. Its contribution is a notice-to-call-through recovery chain. The chain does not replace FCC rules or confidential NORS filings. It gives public agencies, PSAPs, providers, auditors, and researchers a disciplined language for saying what has been verified and what remains an assumption.
Methods
This study used a conceptual synthesis design. The search date was 2026-06-30. The first stage searched the AlexandrAI archive for direct and adjacent work using 18 English terms, including 911 outage reporting , PSAP outage notification , NG911 outage , call delivery failure , NORS 911 , and PSAP notification . The search found no direct archive paper on 911 outage reporting, PSAP notification, NORS 911, or call-through recovery. Adjacent papers on emergency alerts, incident timelines, cooling centers, election incident communications, and notice-to-outcome accountability were screened only to establish a novelty boundary and were not used as factual 911 evidence.
The second stage searched official and public sources using 20 external query angles covering FCC outage rules, eCFR Part 4 and Part 9, NORS, PSAP outage notification, CenturyLink, AT&T VoLTE, the 2014 multistate outage, GAO NG911 implementation reports, National 911 Program data, NG911 standards, CISA continuity guidance, and NENA NG911 materials. Inclusion favored current rule text, FCC staff incident reports, government reports, official program data, standards-body context, and CISA/SAFECOM continuity guidance. Exclusion removed broad funding material, registry pages, procurement guidance, and threat-specific cybersecurity materials that did not add distinct evidence to the outage-reporting chain.
The final corpus contains 21 full-read sources. Each source was coded for the stage it could support: rules and notification duties, incident call-through evidence, reliability architecture, NG911 implementation context, cybersecurity and continuity limits, and national status data. This is a qualitative coding of a purpose-selected corpus, not a statistical estimate of the 911 ecosystem. Table and figure counts in this paper should be read as transparency about the synthesis, not as prevalence claims.
The analytic question was not whether existing FCC rules are adequate as law. It was narrower: what evidence is required before a public statement can move from outage noticed to emergency callers had a verified path to help ? The synthesis therefore treated regulatory artifacts, incident findings, NG911 implementation material, and continuity guidance as different evidence types rather than as interchangeable proof.
Results
The existing accountability infrastructure is already staged. NORS creates a regulator-facing outage-reporting channel, and the FCC describes NORS as a system for rapid, complete, and accurate information about significant communications disruptions. But NORS filings are presumed confidential, so public reporting cannot depend on raw NORS disclosure [[cite:fccNors,ecfrPart4]]. Part 4 also requires providers to notify affected 911 special facilities with material information, including unique outage identifier, provider contact, affected geography, expected effects such as dropped calls or missing metadata, best-known cause, and whether the message is initial, update, or final assessment [[cite:ecfrPart4]].
The timing rule is specific but not outcome-complete. Current Part 4 requires an initial 911 special-facility notification as soon as possible and no later than 30 minutes after discovering an outage that potentially affects the facility, with material follow-up as soon as available and the first follow-up no later than two hours after initial contact [[cite:ecfrPart4]]. FCC 22-88 explains the policy reason: PSAPs need timely and actionable information so they can notify the public and establish alternative ways to reach emergency services [[cite:fcc22_88]]. That confirms why notification is necessary. It also shows why notification is not enough: the public still needs to know what path works.
Reliability certification is another distinct evidence type. Covered 911 service providers must take reasonable measures for circuit diversity, backup power, and diverse network monitoring, and certifying officials submit annual certifications with supporting records retained for two years [[cite:ecfr919]]. The FCC's public 911 reliability page summarizes the same three reliability measures [[cite:fccReliability]]. These controls make outages less likely or easier to detect, but they do not prove what happened during a specific outage window. Certification is architecture and governance evidence. Call-through recovery is incident outcome evidence.
The FCC incident reports show why the outcome stage must be explicit. The 2014 multistate report is especially revealing because redundant infrastructure existed but did not prevent prolonged call failure: a Miami hub could have received traffic, but automatic or manual switchover did not occur until hours after the software fault began [[cite:fcc2014]]. This is a warning against equating the existence of backup paths with verified fallback. Backup capacity becomes meaningful only when detection, alarm management, decision authority, technical switchover, and downstream PSAP handling actually work.
The 2017 AT&T VoLTE report adds a notification-quality lesson. The FCC found that AT&T and subcontractors tried to notify thousands of PSAPs, but the notifications were often unclear, missing important information, and generally took a few hours [[cite:attVolte]]. In a public accountability chain, that finding places PSAP notification between provider detection and caller fallback. A provider can make contact yet fail to give the facility enough actionable information. The reporting unit should therefore distinguish PSAP contacted from PSAP able to mitigate and inform the public .
The 2018 CenturyLink report adds a transport-dependency lesson. The root event was not a local PSAP failure; it was a nationwide fiber-network outage caused by equipment failure compounded by a configuration error. Yet the consequences included disconnected PSAPs, fast-busy signals, lack of reliable 911 access for millions, and at least 886 undelivered 911 calls [[cite:centurylink]]. A call-through chain must therefore cover upstream transport, routing, and aggregation dependencies, not only PSAP-local readiness.
NG911 changes the evidence surface but not the basic logic. The National 911 Program describes NG911 as a digital IP-based system intended to improve resilience, support voice, photos, videos, and texts, and help manage call overload, disasters, and transfers using location data [[cite:ng911Page]]. The FCC's current NG911 services page describes Phase 1 and Phase 2 obligations for originating service providers, including SIP/IP delivery, NG911 delivery points, connectivity testing, and standards-based location data [[cite:fccNg911]]. NENA similarly emphasizes maintaining E911 functions during the IP transition, supporting alternate routing, and enabling call/message/data transfers among PSAPs [[cite:nenaProject]].
Those benefits are real but unevenly deployed. GAO's 2018 report found varied state and local progress and named funding, technology, operations, and governance challenges [[cite:gao2018]]. GAO's 2024 report found that some federal agencies operating 911 call centers had begun NG911 planning or implementation while others had not, and officials cited interoperability, cybersecurity, funding, and data-management challenges [[cite:gao2024]]. The National 911 Profile Database and annual report provide voluntary state-level data and show growing ESInet and text-to-911 adoption, but they also describe self-reported data, non-submission, and data-quality limitations [[cite:profileDb,annual911]].
CISA materials add the continuity layer. CISA's NG911 transition page treats 911 centers as critical emergency-communications components and links cybersecurity and operational resources for 911 systems [[cite:cisaTransition]]. Its cyber-disruption guidance warns that NG911 interconnectivity exposes new threat vectors and that disruptions may cause call backlogs, delayed response, manual operations, or transfers to alternate ECCs [[cite:cisaCyberDisruptions]]. Its cybersecurity primer similarly states that NG911 benefits come with expanded IP attack surfaces that must be managed through risk, response, recovery, and continuity planning [[cite:cisaCyberPrimer]]. The operational implication is that cyber controls and NG911 architecture are inputs; alternate call processing and recovery validation are later-stage evidence.
Notice-to-Call-Through Recovery Chain
Table 4 translates the synthesis into an evidence chain. The chain is designed for public reporting, after-action review, and audit scoping. It is stricter than ordinary outage language because it does not allow evidence from one stage to stand in for another. A filing does not prove notification. Notification does not prove fallback. Fallback design does not prove call delivery. Restoration messaging does not prove location integrity or after-action repair.
The chain's central rule is to publish the weakest verified stage. If a provider filed required reports but PSAP notification quality is unknown, the public claim should stop at regulator notice. If the PSAP was notified but alternate public contact paths were not verified, the public claim should stop before fallback. If fallback was activated but attempted, delivered, and failed call counts are unknown, the public claim should not imply call-through recovery. If calls connected but location or callback data integrity is unverified, the public claim should separate voice connection from complete emergency-call handling.
This rule also clarifies restoration. CenturyLink's 2018 outage report describes the work required after core network symptoms improved: affected services did not automatically come back online and further restoration work was necessary [[cite:centurylink]]. CISA's continuity guidance similarly treats restoring calls from alternate ECCs back to normal operations as a planned step, not a natural consequence of repair [[cite:cisaCyberDisruptions]]. Restoration should therefore be a tested handoff: provider repair, PSAP validation, metadata check, public update, and after-action closure.
The chain can be adapted to hybrid legacy/NG911 environments. In legacy networks, the metadata stage may focus on ANI/ALI and selective routing. In NG911 environments, it may include SIP delivery, PIDF-LO or functional equivalent location objects, ESInet delivery points, and NG911 core-service interfaces [[cite:fccNg911,nenaProject]]. The evidence logic is the same in both cases: a successful path to emergency help is not only a voice circuit or packet path. It is a call, message, or data request delivered to the correct emergency entity with enough information to dispatch help.
Discussion
The practical value of the chain is that it makes 911 outage language less ambiguous. A statement that 911 service has been restored can mean that a transport component is up, that a selective router is reachable, that PSAP trunks are accepting calls, that text-to-911 is available, that location data is arriving, or that all of those have been tested. The public needs the last meaning, but many operational artifacts prove only earlier meanings. A stage model gives public officials a way to communicate uncertainty without hiding it.
For PSAPs and 911 authorities, the chain turns provider notices into mitigation questions. The current Part 4 material-information fields already point in this direction: affected geography, expected effect, cause, and whether the notice is initial, update, or final assessment [[cite:ecfrPart4]]. The chain adds downstream questions: has the PSAP validated call delivery, does an alternate number or text path work, can the center handle shifted call volume, and has the public been told when to use which path? That is the operational bridge from notification to public safety.
For providers, the chain separates compliance from learning. A NORS notification can satisfy a timing obligation, and an annual reliability certification can document architecture and controls [[cite:fccNors,ecfr919]]. But the incident reports show that after-action repair must also address alarm thresholds, change controls, critical-asset inventories, subcontractor dependencies, switchover procedures, and message content [[cite:fcc2014,attVolte,centurylink]]. A provider's strongest public account should show which of those repair commitments were closed, not merely that service returned.
For NG911 planners, the chain resists both optimism and pessimism. NG911 supports interoperability, multimedia, alternate routing, and richer location-aware handling [[cite:ng911Page,fccNg911,nenaProject]]. It also introduces new dependencies and coordination burdens. The National 911 Roadmap identifies work still needed for nationwide interconnection, cybersecurity, validation/testing, performance data, data models, GIS, and operational procedures [[cite:ng911Roadmap]]. The right conclusion is not that NG911 is unreliable. It is that NG911 reliability claims need evidence that follows the same path as emergency calls and data.
For public data programs, the chain suggests what can be reported without exposing sensitive network details. Raw NORS filings are confidential, and detailed network diagrams or vulnerability details may be unsuitable for public release [[cite:fccNors,ecfrPart4]]. A public-safe dashboard could still report stage status: affected PSAPs notified, public fallback activated, attempted emergency-call denominator available, failed-call estimate available, location integrity verified, restoration test completed, and after-action repairs assigned. Such reporting would be more useful than simple outage counts while still avoiding operationally sensitive detail.
Limitations
This paper is a conceptual synthesis, not a legal analysis, performance audit, or empirical measurement of outage frequency. It does not evaluate whether any provider complied with the law in a specific incident, and it does not estimate the national rate of 911 call failure. The FCC incident reports are used as instructive cases because they expose detailed call-through and notification evidence; they should not be generalized as prevalence statistics.
The source base is dominated by U.S. federal rules, federal staff reports, public national program material, and U.S. professional standards context. State 911 laws, local PSAP procedures, vendor contracts, service-level agreements, tribal authority arrangements, and carrier-specific engineering data may impose additional requirements or constraints. A jurisdiction implementing this chain would need to map it to local law, local governance, and actual network architecture.
The paper also cannot solve the confidentiality problem. NORS confidentiality protects sensitive infrastructure and provider information, but public confidence benefits from clear outcome evidence. The chain is a compromise: it proposes public-safe stage statements, not public release of raw filings, call records, or network vulnerabilities. Future work should define minimum public aggregate indicators that are useful to residents without creating security or privacy risk.
Finally, NG911 materials are changing. The FCC's NG911 rules have recent effective dates and information-collection milestones, while the National 911 Program and CISA continue updating resources [[cite:fccNg911,cisaTransition]]. The chain should therefore be treated as a stable conceptual model whose implementation fields evolve with standards, rules, and local deployment status.
Conclusion
911 outage accountability should move from notice language to call-through recovery evidence. The existing system already contains many necessary parts: FCC outage reporting, PSAP notification rules, reliability certification, NG911 transition requirements, incident investigations, national data programs, standards, and continuity guidance. The problem is not absence of evidence. It is that different evidence types are often allowed to blur together.
The notice-to-call-through recovery chain keeps them separate. It asks whether the incident was detected and reported, whether affected PSAPs received actionable information, whether fallback was activated and verified, whether attempted and failed calls were counted, whether location and callback metadata worked, whether restoration was tested, and whether recurrence-prevention repairs were closed. The public claim should stop at the weakest verified stage.
That rule is deliberately conservative. In emergency communications, a premature recovery claim is not only a communications error; it can shape what residents do when they need help. A more careful public record would say exactly what is known: outage noticed, PSAP notified, fallback active, calls verified, metadata verified, service restored, repairs closed. Anything less should be named as an open stage.