Telstra's phantom missed calls: plan for the backlog after a fix

What happened at Telstra

On Wednesday 4 November, Telstra customers across Australia started getting bursts of missed-call and voicemail texts for calls that weren't in their call logs. The Guardian reported that thousands of users were affected. Some of the notifications were for calls made days earlier, and Telstra's Facebook page drew more than 3,000 comments from confused customers. EFTM described one user who got 56 messages in 20 minutes and alerts for calls from more than a week before. Customers of wholesale brands on Telstra's network, such as Woolworths, were also hit.

Telstra said the cause was a fault in its MessageBank service. The company said the problem had been fixed and wasn't the result of a hack, and that triple zero calls, voice calls and mobile data weren't affected. In its apology, Telstra said "We're sorry for how confusing this must be." The Nightly reported that Telstra declared the issue resolved at 5.45pm AWST. At 6.40pm a spokesperson said customers shouldn't expect more delayed notifications, but some commenters said the alerts kept coming. Telstra's public statements also disagreed on timing. One said the issue happened "earlier today" and another said it was identified "yesterday" and fixed "last night". The Guardian reported that Telstra was still investigating the cause. No root cause has been published.

Why a voicemail fault became a trust problem

The faulty component was minor. Calls connected and data kept flowing. Most of the harm came after the fix, when notifications that had been held back were sent all at once. The messages carried nothing to show they were old, so recipients read them as new. People rang back relatives who hadn't called, and one manager phoned a staff member after hours over a call that never happened. Within hours, social media had decided Telstra had been hacked.

Customers already expected the worst because of Telstra's recent history. The company's July outage affected about 45 per cent of its mobile calls and data sessions, according to an independent review by Technology Audit Partners that Telstra released on 1 September. The review found that alarms which would have warned staff were watched only during business hours, by a "limited number" of people. It also found that a clock timing problem had been seen in Melbourne in October 2025 without being logged or raised as a problem ticket. The Australian Communications and Media Authority is still investigating and could fine Telstra up to $30 million. When a provider has that record, any odd behaviour on customers' phones looks like the next big failure.

Restoring a service also releases what was waiting

Most major incident runbooks we see end at "service restored". The MessageBank fault shows why the step after restoration needs its own plan. Restoring most services sends out whatever piled up during the outage: queued emails, SMS notifications, webhooks, integration messages between ERP and CRM systems, payment files and monitoring alerts. Each of these queues has a default replay behaviour, and the person restoring the service often doesn't know it.

You don't need a telco to have this problem. Picture an appointment reminder platform that sends Tuesday's reminders on Thursday morning, or an ERP integration that resends a day of order confirmations. A ticketing tool could email hundreds of "your request has been updated" messages at 2am. A monitoring platform could release a flood of stale alerts and hide the one that matters. In every case the business that sent the messages takes the calls, even when a supplier caused the fault.

In ITIL 4 terms, releasing a backlog is a change to live service. It deserves a quick risk assessment covering what's in the queue, how old the items are, who receives them and whether the recipient can tell they're late. Problem management also applies. The Telstra review's point about an unlogged timing problem in October 2025 is a warning about small anomalies that never become problem records. Our ITIL 4 framework page covers how incident, change and problem practices connect.

What it means for NZ businesses

Most NZ organisations rely on services that queue and replay messages outside their control. These include telco voicemail and SMS, third-party SMS gateways, email delivery services, payment providers and SaaS platforms with their own notification engines. Telstra's fault also reached customers of a brand that resells Telstra's network, so some of them may not have known which network they were on. Many NZ businesses have the same blind spot about which carrier or gateway sits behind their mobile plans and messaging tools.

Security is the other angle. A burst of phantom contacts that appear to come from known numbers makes staff more likely to trust an unexpected callback or message. A fraudster who calls during that confusion and claims to be "following up on the missed call" will get a better hearing than usual. We'd assume any public messaging glitch will be followed by attempts to exploit it, and we'd brief the service desk before customers start ringing in.

Practical next steps

• List your queues and how they replay. For each system that sends notifications or passes messages between applications, record what happens to held items after an outage. Note whether they're replayed in full, throttled, deduplicated or dropped after a time limit, and who can change that setting.
• Add a backlog decision to your major incident process. Before you close an incident, a named owner should decide whether to purge, replay, replay with a delay marker or throttle the backlog. Record the decision on the incident ticket.
• Make late messages identifiable. Where your platforms allow it, keep the original timestamp and add a visible "delayed" label to anything sent more than an agreed time after it was created.
• Write the customer notice in advance. Prepare a short message for duplicate or delayed notifications. It should say whether security was affected and tell people how to check that a contact is real. Send it before or alongside the backlog, so people don't learn about the fault from social media first.
• Brief the service desk. Give the desk a script for the incident and a reminder to verify unexpected requests by calling back on known numbers.
• Monitor queue age as well as uptime. A service can report healthy while its outbound queue grows for hours. Route that alert to someone who's on call around the clock, and avoid the business-hours-only coverage the Telstra review criticised.
• Log small anomalies as problems. If a technician sees something odd and fixes it, open a problem record anyway so the pattern shows up later.
• Ask your suppliers. Ask your telco, SMS gateway and key SaaS vendors how they handle backlogs after an outage and whether they'll tell you before they release one. Put the answers in your supplier records.

Automating the routine parts, such as queue-age alerts and the delayed-message label, takes some of the judgement out of the stressful moment after a fix. Our process and automation work is a good place to start if your notification flows cross several systems. Telstra hasn't published why MessageBank held messages for days. The more useful question for most NZ teams is what their own systems would send the moment service comes back.