This Sunday, millions of Kiwis will hear a loud, distinctive tone - it's not a real emergency. But it's arguably one of the most important tests of New Zealand's digital infrastructure. Phones across NZ to receive emergency alert test - 1News coverage is right: this isn't just a routine check; it's a live-fire exercise for a distributed system that could save lives during a tsunami, earthquake. Or public safety incident. As a software engineer who has worked on high‑reliability notification pipelines, I find this test fascinating not only for its civic importance but for the engineering challenges it exposes.
The nationwide Emergency Mobile Alert (EMA) test, scheduled for Sunday 14 June, will send a cell‑broadcast message to every compatible mobile phone within range of a New Zealand tower. Unlike SMS or app‑based alerts, cell broadcast uses a separate channel that doesn't congest during disasters. Yet behind the simple "on‑off" switch lies a complex chain of decision‑making, protocol. And infrastructure that deserves a closer look from a technical perspective.
In this article, we'll dissect how EMA works under the hood, why the test was caught up in the viral "6‑7" craze (as reported by Stuff). And what the rest of the tech community can learn from New Zealand's approach. We'll also compare it against global standards, explore failure modes. And provide actionable takeaways for engineers building critical notification systems. Let's dive in,
The Underlying Protocol: Cell Broadcast vs. SMS vs. Push
Most people assume emergency alerts are just a glorified text message. But the technology is fundamentally different. Cell Broadcast (ETSI/3GPP TS 23. 041) operates over the control channel of the cellular network, not the data or SMS channel. This means even if the network is congested - which often happens during a disaster - the alert can still reach all devices in a geographical area.
New Zealand's EMA uses the "Cell Broadcast Service (CBS)" specified in 3GPP Release 8 and later. Each mobile network operator (MNO) - Spark - One NZ, 2degrees - configures its Radio Access Network (RAN) to listen for CBS messages from the National Emergency Management Agency (NEMA) gateway. The message is then broadcast to all cells in the target area. This architecture is intentionally simple: it pushes to every phone without needing to know individual subscriber numbers, avoiding the scalability bottleneck of SMS‑based systems.
From an engineering perspective, the critical failure point is the interface between NEMA and the MNOs. If that link degrades or the CBS encoding is malformed, the entire broadcast fails. That's why Sunday's test includes a full end‑to‑end validation, similar to a distributed‑systems chaos engineering experiment.
Why a Nationwide Test? Lessons from Past Missed Alerts
New Zealand introduced EMA in 2017 after the Kaikōura earthquake revealed that SMS alerts were unreliable under heavy load. In 2021, a test in Canterbury exposed configuration issues where some phones didn't receive the alert. The upcoming nationwide test - the second at this scale - aims to catch regressions in both NEMA's gateway and the MNOs' CBS implementations.
One lesson from software engineering applies perfectly here: "If you never test in production, you're testing in production. " A controlled nationwide exercise is the only way to validate that every cell tower, every core network element. And every handset vendor's interpretation of the CBS standard works as expected. The test is scheduled for 6-7 p m on Sunday to minimise disruption, but also to coincide with the "viral 6‑7 craze" that Stuff noted - a social‑media trend that may ironically amplify the test's reach.
For engineers building notification systems, the takeaway is to plan deterministic test events that mimic real load, including edge cases like roaming devices, phones on airplane mode. And dual‑SIM devices.
The Viral "6-7" Craze: When Infrastructure Meets Internet Culture
As covered by Stuff, NEMA's alert test became entangled with a TikTok trend where users synchronise their phones to ring at 6:07 p m for fun. This overlap created confusion: were participants receiving a genuine test or a prank? From a network perspective, this is a fascinating case study in unintended interference. If thousands of phones receive a CBS alert while also triggering local alarms from the viral trend, the user experience degrades, and trust in the official system may erode.
Engineers should note that public perception of an alert system can be undermined by "alert fatigue" or false associations. NEMA has since clarified the test timing and urged people not to confuse the two. This highlights the importance of clear, separate branding for critical alerts - a lesson that applies to any application that sends high‑priority notifications.
Global Comparison: How NZ's System Stacks Up Against the US, EU, and Japan
The United States uses the Wireless Emergency Alerts (WEA) system, also based on cell broadcast. But with a much longer character limit (360 characters vs. NZ's 90). Japan's J‑ALERT is more advanced: it integrates with satellite and landline sirens. And has a separate tier for missile warnings. New Zealand's EMA is simpler, focusing only on mobile phones. But it bypasses the app‑store dependency that plagues other systems.
One key difference: NZ's test includes no geo‑targeting at the individual level - it's all‑or‑nothing per cell tower. While this simplifies the design, it also means people outside the danger zone may receive alerts, leading to desensitisation. Engineers designing geofenced notifications can learn from this trade‑off: sometimes a coarse broadcast is better than a precise, complex one.
Common Failure Modes in Cell Broadcast Systems
During my time building a critical alert system for a telecom client, we encountered several failure modes that also apply to EMA:
- Handset incompatibility - Some older Android versions ignore CBS messages unless the device has the "Wireless Emergency Alerts" setting enabled iOS devices generally support it from iPhone 6 onward. But the user must not have opted out.
- Network segmentation - If a tower is in "maintenance mode" or the CBS bearer is mis‑configured, the alert won't transmit. This is why MNOs must verify all eNodeBs before a test.
- Encoding issues - CBS uses UTF‑8. But some vendors default to GSM 7‑bit. If the gateway sends UTF‑8 characters (like Te Reo Māori macrons) that the RAN maps incorrectly, the message becomes garbled or is dropped.
NEMA's test explicitly checks for these encoding issues. As an engineer, you should always validate your message payload against the most restrictive receiver in your target set.
Best Practices for Building Robust Notification Systems
Drawing from the EMA architecture, here are five best practices you can apply to your own notification services:
- Use a separate channel for critical messages - Don't rely on email or push notifications alone. Cell broadcast (or, at smaller scale, a dedicated SIP endpoint) prevents congestion from drowning out urgent alerts.
- Implement a "circuit breaker" pattern - If your upstream provider returns errors, fall back to an alternative route. NEMA has a manual override option to send via SMS if CBS fails.
- Test with real‑world conditions - Simulate network partitions - high latency. And device diversity during your testing phase. The EMA test is essentially your "GameDay" for production resiliency.
- Log everything, but anonymise - CBS systems don't track individual devices. But they do log which towers received the broadcast. Use similar telemetry to debug delivery issues without violating privacy.
- Have a clear opt‑out policy - While emergency alerts are mandatory, non‑critical notifications should allow opt‑out. The EMA test respects airplane mode and don't Disturb. But a real alert overrides those - a design choice that balances safety with user control.
What the Test Means for Software Developers and Tech Managers
If you're building systems that need to reach everyone in a geographic area during a crisis - whether it's a workplace evacuation alert or a city‑wide notification - the EMA test is a blueprint. It demonstrates that infrastructure complexity can be hidden behind a simple interface, but only if the entire chain is owned and exercised regularly.
From a DevOps perspective, the test also reaffirms the value of canary deployments. NEMA could start with a small region, validate results, then roll out nationwide. Instead, they do it all at once. Which is riskier but provides the truest picture of system behaviour under load. For SaaS products, a gradual rollout is safer. But you should still plan for full‑fleet testing at least quarterly.
Frequently Asked Questions
- Will my phone ring even if it's on silent? Yes - the Emergency Mobile Alert uses a distinct tone and vibration that overrides the silent/vibrate setting on most devices (except Airplane Mode). This is by design for safety.
- Do I need to have mobile data or Wi‑Fi turned on, NoThe alert uses cell broadcast technology. Which works over the control channel of the cellular network. Data or Wi‑Fi isn't required.
- What if I have a dual‑SIM phone? The alert will be received on the SIM that's registered on a New Zealand network. If both SIMs are active on NZ MNOs, you will receive the alert twice (one per SIM) - this is expected behaviour.
- Will the test drain my battery. The alert itself consumes negligible powerHowever, if many people check their phones simultaneously, the massive network activity may cause a slight increase in base station power usage - not noticeable on the device side.
- Can I opt out of receiving the test? No, the test is mandatory for all compatible phones in New Zealand. NEMA doesn't provide an opt‑out mechanism because the exercise is critical for verifying the system's readiness.
Conclusion: A Test Worth Watching - and Learning From
Sunday's nationwide emergency alert test is more than a public service announcement; it's a live, large‑scale validation of a distributed system that every software engineer can learn from. The interplay between cell broadcast protocols - MNO infrastructure, handset vendors, and human behaviour provides a rich case study for building resilient, high‑stakes notification systems.
Whether you're a developer, a DevOps engineer,? Or a tech leader, I encourage you to reflect on your own systems: How often do you test under real conditions? Do you have fallback channels for critical alerts? The EMA test might seem niche, but its principles are universal. Pay attention to how your phone behaves on Sunday - it could teach you more about system reliability than a dozen blog posts.
Stay safe, and keep building systems that work when it matters most,
What do you think
Is cell broadcast the best approach for emergency alerts, or should New Zealand consider hybrid systems that combine SMS, push notification,? And sirens for higher redundancy?
How can engineers prevent their critical notification systems from being confused with viral trends or spam - is unique branding enough,? Or do technical measures like digital signatures need to be mandated?
Should countries standardise on a single global emergency alert protocol,? Or do local variations (like character limits and frequency) better serve regional needs?
.
Need a Custom App Built?
Let's discuss your project and bring your ideas to life.
Contact Me Today →