NTA Outage History

Started Sep 23, 2026, 05:57 PM UTC· resolved Sep 24, 2026, 06:34 AM UTC

1. investigating Sep 23, 2026, 05:57 PM UTC

   We are currently investigating this incident.

2. monitoring Sep 23, 2026, 09:31 PM UTC

   Inbound, outbound and BLF have been working for some time now, however we are continuing to monitor. Investigations confirmed there has been a major outage with one of our datacenter's links which required some services to be manually switched over. We are still awaiting further information and resolution on this link so this incident will remain in a monitoring state until all connections resume and have been confirmed working.

3. resolved Sep 24, 2026, 06:34 AM UTC

   This incident has been resolved. The datacentre link was restored shortly before 05:00\. Registrations have since returned to normal, and services at the affected site have been brought back online and monitored to confirm stability.

4. resolved Sep 28, 2026, 12:18 PM UTC

   $19

Read the full incident report →

Started Sep 16, 2026, 06:30 AM UTC· resolved Sep 16, 2026, 08:41 AM UTC

1. identified Sep 16, 2026, 06:30 AM UTC

   We are aware that some of the internet connections provided by one of carriers are currently down. We are currently investigating this incident. This does not affect all our customers

2. resolved Sep 16, 2026, 07:11 AM UTC

   This incident has been resolved.

3. resolved Sep 16, 2026, 08:41 AM UTC

   The internet carrier ITS has resolved this incident and is monitoring their network for any outstanding issues..

Read the full incident report →

Started Sep 04, 2026, 12:01 PM UTC· resolved Sep 04, 2026, 12:27 PM UTC

1. investigating Sep 04, 2026, 12:01 PM UTC

   We are currently investigating an incident regarding the delivery of emails to Microsoft based accounts. This issue is affect the delivery of login codes for Mobex as well as the delivery of emails for reporting and call recording only.

2. resolved Sep 04, 2026, 12:27 PM UTC

   This incident has been resolved. The issue has been traced to a poor IP reputation from Microsoft towards one of our email & FTP servers. This server has been adjusted to workaround this issue. We will continue to raise enquiries with Microsoft as to why our IP was blocked.

Read the full incident report →

Started Feb 26, 2026, 03:42 PM UTC· resolved Feb 27, 2026, 08:33 AM UTC

1. investigating Feb 26, 2026, 03:42 PM UTC

   We are currently investigating this incident at our datacentres, which is affecting our network and the abilility to make and receive calls..

2. identified Feb 26, 2026, 03:50 PM UTC

   We are continuing to work on a fix for this incident..

3. identified Feb 26, 2026, 04:21 PM UTC

   Engineers have been dispatched to one of the datacentres to work on the issue.

4. identified Feb 26, 2026, 04:45 PM UTC

   Whilst we do have failover mechanisms in place, these only apply when the primary connection is hard down. As it currently flapping, this prevents the system moving into failover as the connection is not hard down. Unfortunately, this has put the system in a state where we will have to manually disconnect the link in order to utilise the other links. Our engineers are at site at the datacentre and working on the servers.

5. monitoring Feb 26, 2026, 04:55 PM UTC

   We now have a restricted service back-up and running, but services such as BLF will not be fully operational for a while as we concentrate on getting things running back as normal.

6. monitoring Feb 26, 2026, 05:38 PM UTC

   Whilst services are fully restored, we are waiting for an update from our suppliers as to the reason for the outage. Once we have that,a reason for outage will be issued..

7. resolved Feb 27, 2026, 08:33 AM UTC

   This incident has been resolved. If your handset is still offline, please power cycle it. A reason for the outage will be issued after a thorough investigation into the cause has been conducted. Sorry for any inconvenience this may have caused you.

8. monitoring Feb 27, 2026, 04:09 PM UTC

   At 15:42, our upstream connectivity supplier experienced a service outage, causing interface instability (“flapping”) and subsequent service disruption within our network environment. At 15:50, investigations confirmed that the primary customer impact was related to call completion. The instability affected SIP signalling, causing a core service to become unresponsive and preventing calls from completing successfully. Also, preventing access to disable the affected routes and allow the Disaster Recovery to kick in At 16:21, NTA engineers managed to disable the affected interfaces to stabilise the platform and initiate established disaster recovery procedures. At 16:55, service stability was progressively restored following supplier recovery actions, and all services were fully operational and performing within normal parameters. NTA has already scheduled a programme of infrastructure improvements for April, including the migration from the current connectivity supplier to an alternative provider that will deliver enhanced redundancy while improving service resilience. This programme also includes increased rack capacity, deployment of new server infrastructure, and a major platform upgrade to support modern technologies, including AI capabilities and future business growth.

Read the full incident report →

Started Dec 31, 2025, 01:39 PM UTC· resolved Dec 31, 2025, 01:39 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Oct 10, 2025, 09:16 AM UTC· resolved Oct 10, 2025, 09:49 AM UTC

1. monitoring Oct 10, 2025, 09:16 AM UTC

   This morning, we had a brief issue with our Web Server and APIs, which caused a temporary disruption to services such as Wallboards and MobeX Web. We implemented an immediate fix; therefore, these services are now operational. We are currently monitoring the result..

2. resolved Oct 10, 2025, 09:49 AM UTC

   This incident has been resolved, and we will continue to monitor our servers..

Read the full incident report →

Started Sep 01, 2025, 09:56 AM UTC· resolved Sep 01, 2025, 02:35 PM UTC

1. investigating Sep 01, 2025, 09:56 AM UTC

   We are currently investigating a fault with invoice generation on [ntalk.co.uk](http://ntalk.co.uk). All invoices are now being regenerated. This could take up to the end of the business day. Any invoices dated 01/09/2025 will be replaced with a new invoice. Please email [[email protected]](mailto:[email protected]) for any questions. Updates will be available on this status page when available. We apologise for any inconvenience caused..

2. identified Sep 01, 2025, 10:48 AM UTC

   The invoice generation has been restarted.

3. resolved Sep 01, 2025, 02:35 PM UTC

   All 01/09/2025 invoices have now been generated. Please go to Reports > Invoices on the portal. Thank you for your patience..

Read the full incident report →

Started Jul 11, 2025, 09:58 AM UTC· resolved Jul 14, 2025, 11:42 AM UTC

1. investigating Jul 11, 2025, 09:58 AM UTC

   We are currently aware of an incident affecting the telephone lines. We are currently investigating the cause. We will send out further updates when we find out more information..

2. identified Jul 11, 2025, 10:33 AM UTC

   BLF's have temporarily been disabled while service is fully restored.

3. identified Jul 11, 2025, 11:08 AM UTC

   The outage has been identified as a network issue, which is being fully investigated. All services have been restored to normal, apart from the BLFs, which will be restored later today. An RFO will be issued following the investigation has been completed.

4. monitoring Jul 11, 2025, 01:54 PM UTC

   We implemented a fix and are currently monitoring the result..

5. resolved Jul 14, 2025, 08:19 AM UTC

   This incident has been resolved and the BLF lights have been re-enabled. An RFO will be issued later.

6. resolved Jul 14, 2025, 11:42 AM UTC

   RFO Friday 11th July 10:13 A router card failure was identified at one of our Datacentres in Enfield. Although the router failure was only for 10 minutes and returned to service at 10:23, it caused an issue with the routing of calls whereby either the call was terminated or it made the call became unanswerable. 10:50 After identifying the cause of the failure, the affected card was removed from service and the BLFs were disabled, to allow the routing to stabilise. 11.42 The fault was resolved, with services being fully restored, apart from BLFs, due to the load that would suddenly be added to the servers Weekend of 12.07.25 to 13.07.25 - BLFs were switched back on and all services to the network made fully active To prevent this incident from reoccurring, the affected router will be replaced on the weekend starting 19.07.25.

Read the full incident report →

Started Jun 02, 2025, 10:00 AM UTC· resolved Jun 04, 2025, 10:28 AM UTC

1. identified Jun 02, 2025, 10:00 AM UTC

   We are aware of the C30 handsets rebooting/cutting off. This has been identified as an issue with LDAP. Please reset thee handset by pressing the OK button for 10 seconds to clear the configuration out of the handset to clear this. This is also causing Cloud Phonebook issues on other handsets, we are continuing to work on a fix for this incident..

2. identified Jun 03, 2025, 11:16 AM UTC

   We will be reprovisioning the C30 devices, after that it will be A, B, E, F, and then C33 and Ds which will take one hour per group After this,the number of entries in the Cloud Phonebook will be worked on followed by the ringtones.

3. monitoring Jun 03, 2025, 01:46 PM UTC

   We implemented a fix and are currently monitoring the result. We are sending the connections directly to the LDAP server therefore bypassing the haproxy now and removing anything obstruction in the chain.

4. monitoring Jun 03, 2025, 03:14 PM UTC

   Yealink handsets will be reprovisioned after 18:00 tonight which should resolve the ringtone issues.

5. resolved Jun 04, 2025, 10:28 AM UTC

   Whilst we are aware there are a few extensions with problems still, we will resolve those shortly. Please see below the RFO In the new implementation of our Cloud Phonebook we decided to use some proxies to improve its availability and also add a few new features. We opted for using HAProxy, a well-known open-source project, that has been in use for many years (it is responsible for handling provisioning, wallboards, MobeX plus many internal projects). We also developed an LDAP Proxy to allow us to add a cache to improve the responses and sorting (something that models like C30 and below cannot do). The solution was tested internally and worked fine. Unfortunately, while moving it to production, we started to receive reports that the Cloud Phonebook was failing and some devices (A10, B20 plus C30) were rebooting. After the initial investigation, we found that some of the behaviours were causing the connections to be denied, so we improved it to handle an increase in traffic that we couldn't reproduce during the internal tests. However, the rebooting of the devices was unexpected and the only real hypothesis was that something in the middle between the LDAP servers and the devices was creating packets that the devices couldn't handle. Initially, we decided to stop using the LDAP Proxy as it could be sending the wrong packets which started to reprovision the devices. This is a process that could take several hours because it would not be good to have all the devices coming to the system at the same time. After the C30 devices were reprovisioned, we kept monitoring the systems and took notes of reports. There was also a possibility that the devices that were still rebooting were the ones we could not reach for reprovisioning because they were in use at the time that we sent the requests. After more internal checks we noticed that this was not the case, so the only other piece of software that could be causing the reboots was the HAProxy itself. The fact that it was affecting only the old Hosted models probably meant that they couldn't handle some packets that were being sent to them. We started to reprovision all devices to connect directly to the LDAP servers, avoiding any proxies in the middle, after this was done no more reboots were detected. This means that we can't use the HAProxy with the LDAP servers. However, it doesn't mean that we will not be implementing our LDAP Proxy again in the near future, since the LDAP Proxy was behind the HAProxy, it is possible that the LDAP Proxy was not failing, but just facing the same issues with the HAProxy too. This implementation will be done in a slow-paced rollout to avoid causing more issues with the cloud phonebook access in the future. The new LDAP Proxy is a really important part of our new cloud phonebook strategy because it will make the Dir requests much quicker and it'll add sorting support for models A, B plus C30. We really do apologize for this unexpected issue and will keep you updated on our plans in the future.

Read the full incident report →

Started Mar 24, 2025, 09:37 AM UTC· resolved Mar 24, 2025, 02:38 PM UTC

1. investigating Mar 24, 2025, 09:37 AM UTC

   We are currently investigating this incident. However, we have been advised that this is due to firmware changes on Draytek routers. Please contact your IT team for assistance.

2. identified Mar 24, 2025, 10:47 AM UTC

   Please see the inserted link for further information on this matter .

3. monitoring Mar 24, 2025, 01:07 PM UTC

   We have been advised of a fix for the current issue with the Draytek routers. Please disable SSL VPN and Remote management on the router.

4. resolved Mar 24, 2025, 02:38 PM UTC

   As the issue is down to the use of the Draytek routers and not a direct NTA issue this is deemed to be a non-NTA incident and only an advisory notification and therefore the issue will be closed.

Read the full incident report →

Started Oct 28, 2024, 09:22 AM UTC· resolved Oct 28, 2024, 11:42 AM UTC

1. investigating Oct 28, 2024, 09:22 AM UTC

   We are aware that some of the handsets are showing the incorrect time. We are currently investigating to resolve this issue. Sorry for any inconvenience this may cause..

2. identified Oct 28, 2024, 09:53 AM UTC

   The issue has been identified and a resolution is being put in place..

3. identified Oct 28, 2024, 10:31 AM UTC

   The issue will be rectified within the next 30 minutes, you may see your handset being reprovisioned during this time.

4. resolved Oct 28, 2024, 11:42 AM UTC

   This incident has been resolved. If your handset is still showing the incorrect time please reboot the device.

Read the full incident report →