The chaos that unfolded at Indira Gandhi International Airport, New Delhi, on 6–7 November 2025 was in a different league altogether. When the Automatic Message Switching System (AMSS) in the air traffic control (ATC) stack faltered, controllers were forced to draft flight plans by hand and meter departures manually—at the nation’s busiest aviation hub. Even as officials rushed to issue sketchy press notes and cryptic tweets ruling out a cyberattack, the paralysis deepened by the hour. The disruption swelled from a few dozen to several hundred delayed and diverted flights; whether the final count was 700 or 800 is almost beside the point. The collapse of a single message-handling backbone—without a seamless failover—throttled India’s airspace capacity and laid bare a stunning level of institutional fragility.
Yes, air travel has its everyday irritants: long queues, temperamental baggage belts, the odd lost bag, eye-watering sandwich prices, brusque security staff—the seasoned traveller grimaces and moves on. Even the headline-grabbing global blue-screen in July 2024—a faulty third-party update that bricked Windows machines worldwide—mainly crippled check-in desks and baggage systems. That was a front-of-house IT failure: miserable, costly, and highly visible, but it didn’t touch the tools controllers use to keep aircraft safely separated. Delhi was different. This time, the strain hit the safety core.
Why this wasn’t “just another outage”
The AMSS (and its successor AMHS) sits at the core of message distribution—flight plans, clearances, and operational exchanges—across ATC domains. With AMSS down, you don’t merely inconvenience passengers; you choke the rate at which aircraft can be safely launched and sequenced. Mature, mission-critical systems avoid this with dual-site, hot-hot redundancy, automatic failover, staged change control, and tested, time-boxed rollbacks. Delhi’s manual reversion tells us those controls were either absent, untested, or misconfigured.
The opacity is familiar. Officials did not confirm a cause even as speculative explanations swirled. This ambiguity, coupled with the lack of a public post-incident timeline, underlines what ails the system: weak change governance and minimal public accountability for high-stakes software changes.
Spoofing over the capital changes the risk calculus
Compounding the outage, Delhi experienced GPS spoofing in the same window—false satellite signals misleading onboard navigation systems, prompting cockpit alerts and diversions. That is no longer about surly queues; it is an aviation-safety and national-security problem seated squarely in the radio-frequency spectrum. India has already seen spoofing and jamming creep along sensitive corridors close to the international border; Delhi’s inclusion means the country’s densest traffic node is exposed to hybrid interference in the very week its digital backbone buckled. That combination—degraded navigation integrity plus crippled messaging—is how multiple safety nets line up to create the rare, catastrophic event.
Unlike check-in counters or baggage carousels, navigation integrity and controller tooling are safety-critical. This is why comparing Delhi to the 2024 software episode is instructive: common-mode failures in homogeneous IT supply chains can cripple customer-facing operations; but ATC-class failures threaten separation, runway occupancy time, and collision risk. The former produces pictures of queues; the latter demands root-and-branch engineering reform.
ECIL, AAI, DGCA—and any role for the Air Force
ECIL (vendor/technology provider): For years, India’s ATC messaging has relied on an ECIL-built AMSS across multiple airports. If a “routine update” or configuration change triggered a core failure, then the vendor’s change management, regression testing, rollback readiness, and on-site recovery support are squarely in focus. ECIL (or any vendor on the stack) must disclose: what changed, what tests passed, what failed, and why the system did not fail over automatically.
AAI (operator and owner of the ATC stack): The Airports Authority of India runs the network and bears operational accountability. AAI must explain the current deployment state at Delhi: AMSS vs AMHS, the intended data-centre/disaster-recovery pairing, the switchover playbook, and the cadence of failover drills. If upgrades promised “resilience,” why did controllers reach for pen-and-paper? AAI also owns the duty of care to publish a clock-accurate incident timeline and a corrective-action plan with milestones.
DGCA (regulator and safety overseer): The Directorate General of Civil Aviation sets the safety bar. Beyond opening an inquiry, DGCA should mandate a transparent technical post-mortem; require quarterly, audited failover exercises for critical ATC systems; tighten change-window controls; and issue directives on GNSS-interference procedures (including RAIM/GAGAN alerts and crew/ATC coordination). Enforcement must be visible: findings, deadlines, and consequences for non-compliance.
Indian Air Force (civil-military coordination and security): Delhi’s airspace is a blended civil-military environment. While the IAF does not run civil ATC, it plays a key role in airspace management, contingency coordination, and national-security posture. With spoofing reported over the capital, the IAF’s signals-intelligence and spectrum-monitoring assets—working with DGCA, AAI, and CERT-In—should be harnessed to map interference sources, attribute patterns, and harden navigation procedures. On days when civil systems are degraded, joint playbooks for traffic prioritisation, diversions, and temporary route structures should be ready to activate.
The vendor stack—and the chasm between promises and practice
India’s network has a migration path to a newer AMHS billed for performance and resilience, including a primary data centre and a disaster-recovery site. If so, why did a Delhi-centred fault still collapse messaging throughput and force manual fallback? Either the migration remains partial, the failover path didn’t engage, or the cut-over left critical single points. The public deserves clarity on the actual deployment state in Delhi on the day of failure—and a dated plan to close the gaps.
The logical, technical case for anger
Anger is warranted—but it must be disciplined by engineering logic:
Change control: What pre-deployment tests (unit, integration, soak) and canary releases preceded the AMSS change? Where is the rollback plan and the mean-time-to-recover record for the switchover? If basic change hygiene failed, that’s a management choice, not bad luck.
Redundancy that actually works: Did a hot-hot peer assume load automatically? Was there automatic replay of queued messages? If not, why have we invested in upgrades marketed for resilience?
Operational drills: When were the last failover exercises run for Delhi’s message-handling path? Where are the quarterly drill reports? If drills aren’t routine and recorded, they aren’t steering behaviour.
GNSS resilience: Are RAIM/GAGAN integrity flags integrated into ATC decision support and airline SOPs for Delhi? Are multi-constellation receivers (GPS/GLONASS/Galileo + NavIC L1) mandated for critical airside operations? What’s the spectrum-monitoring footprint over NCR and how is it shared across agencies?
What accountability and reform should look like
Publish a technical post-mortem in 30 days. List software versions, change tickets, approvers, regression matrices, the precise failure timeline, and why failover didn’t bite. Name the vendors and the accountable officers along the approval chain.
Harden the architecture, not the press release. Complete the AMHS cut-over with provable DC/DR switchover, enforce split change windows, and adopt immutable build artefacts with pre-approved rollback images. Run monthly automatic failovers during low-traffic hours and publish success metrics.
Treat GNSS interference as a national-security threat. Stand up an NCR-wide interference-detection mesh (fixed sensors, airline data, and crowd-sourced receivers), fuse it with DGCA/IAF/CERT-In response playbooks, and publish weekly heat maps through the winter. Mandate multi-constellation and anti-spoofing-capable avionics for critical operators and fast-track NavIC enablement where feasible.
Independent audit, not self-grading. Commission a cross-disciplinary review—aviation safety, ICS/OT cyber, and spectrum engineering—reporting to Parliament’s Standing Committee. Tie budget release to dated milestones and public compliance summaries.
Consequences for negligence. If testing gates were skipped, if failovers were not maintained, if approvals were rubber-stamped, heads must roll—across engineering, vendor, and bureaucratic lines. A culture that names responsibility is the only culture that learns.
The bottom line
That this chaos erupted from software built by our very own Electronics Corporation of India Limited (ECIL) makes it all the more disquieting. ECIL is, after all, a flagship of India’s technological self-reliance—anchored in the vision of Atmanirbhar Bharat, Digital India, and Make in India. When systems so central to national pride collapse in real time, it exposes not just technical fragility but an alarming gap between rhetoric and readiness. Passengers will tolerate the ordinary discomforts of modern air travel—the queues, the overpriced sandwiches, the occasional lost bag. But they will not, and should not, accept a system where the core of our air traffic control infrastructure fails and spoofed skies hover over the national capital in the same week—while the political leadership, including Jyotiraditya M. Scindia, Union Minister for Civil Aviation, remains conspicuously silent, even on X (formerly Twitter), a platform on which he is otherwise notably active.
This is not fate,not even a freak accident; it is the predictable consequence of accumulated technical debt, complacent procurement, and performative oversight. Fix the governance. Fix the architecture. Show your work in public. Because next time, the difference between a miserable travel day and a national tragedy may be measured in minutes of message loss and metres of positional error—not in social-media outrage.