Connectivity Interruption: 15/05/2026

  • Saturday, 16th May, 2026
  • 08:37am

On the 15th of May, 2026, several of our services were interrupted due to a connectivity issue, leaving multiple servers on our network unreachable for several hours.

Servers themselves remained fully operational throughout the incident - the issue was not with the servers or any data stored on them, but with the ability to reach them from the internet.

This announcement is to catalogue what happened, how it was resolved and what we are doing to prevent similar issues in the future.

What Happened?

At 12:35 AEST, our network monitoring platform detected that servers in Sydney Next DC1 were not reachable. Initially, it appeared to be isolated to just certain servers in Sydney, but then spread to our servers in Brisbane, Melbourne and Perth.

By 13:30 AEST, our upstream provider confirmed that it was a large-scale distributed denial-of-service attack targeting their entire autonomous system.

Multiple attempts were made to bring the network back online, but the attack resumed each time.

This was a very large attack, consuming over 600Gbps of inbound traffic. Approximate number of IP Addresses affected by this attack is 9,700.

The primary upstream provider (Superloop) was unable to handle the mass of traffic being routed through its network. The secondary upstream provider was also unable to handle the flow overload, but did provide some connectivity during the attack.

This attack affected not just UpTime servers but many other Web host providers and online services in Australia.

Not all servers were affected, as we have different upstream providers. We have listed each server affected below in the Details Information section.

A flow-on effect was that the UpTime website and our two primary nameservers were also affected.
With the nameservers unreachable, other servers unaffected by the attack could not have their names resolved.

Although we were posting updates on the UpTime website, it was also uncontactable for many clients.

Is This A Security Issue?

No, the attack was not targeted at UpTime directly. The attack was on the network of our upstream provider via the SuperLoop network.

The attack did not involve any attempts to break into the UpTime network or its servers.

Customer data was not at risk at any point. This was a network-level attack only - no systems were accessed or compromised.

When And How Was It Fixed?

At approximately 6:30 PM AEST, our provider engaged GSL Networks (Global Secure Layer) - a carrier that specialises in high-capacity, inline DDoS mitigation at the ISP level. GSL's infrastructure was able to absorb and filter the attack traffic, allowing them to restore their network through a clean transit path and re-establish full connectivity to our hosted services.

What are we doing to prevent this again?

Global Secure Layer is now in place to protect against similar attacks, and we are working with our providers to protect UpTime and its clients.

Two unexpected issues have been highlighted by this incident.

1. Nameservers

NS1 is located in Next DC Sydney
NS2 is located in Next DC Melbourne

Geographically separating these two servers would have been enough to keep name resolution online if one DC were offline for any reason.
Because this attack affected the entire network, both servers were unreachable.

This morning, we installed and configured NS3.  This server is on a completely separate data centre provider and network from ns1 and ns2.
All cPanel servers are now publishing DNS information to this new server.

The third nameserver now provides additional redundancy for domain name lookups.

If your hosting account is cPanel, you should update your domain nameservers to the following to utilise this new redundancy:

ns1.uthost.au
ns2.uthost.au
ns3.uthost.au

Note: If your hosting account is on Plesk, this does not apply. Plesk uses a different DNS configuration that was not affected by this incident.

2. UpTime Website availability

Our website, client portal and network status are all hosted on their own dedicated server.  This keeps it separate from all other servers and accounts on our network. Normally, this would have been enough to maintain communication with clients during an incident.

In this case, though, our website was also directly affected, and clients were not able to log helpdesk tickets or check the status of their hosting accounts.
Our phone system was online at all times during the incident, but we were unable to handle all calls coming into our support team.

We also use cPanel to host our website, and unfortunately, it does not offer a high-availability option. 

We have now migrated our website and client area to an isolated network and a different data centre.  This will ensure that our site remains online regardless of what happens across our network.


Detailed Information

Which servers were affected:

BNE1

Start Time End Time Down Info
15 May 13:30 15 May 14:10 40min Error
15 May 13:02 15 May 13:23 21min Error

BNE2

Start Time End Time Down Info
15 May 13:30 15 May 14:09 39min Error
15 May 13:02 15 May 13:22 20min Error

MEL1

Start Time End Time Down Info
15 May 13:29 15 May 14:10 41min Error
15 May 13:06 15 May 13:23 17min Error

PER1

Start Time End Time Down Info
15 May 16:49 15 May 16:50 1min Error
15 May 13:29 15 May 14:12 43min Error
15 May 13:18 15 May 13:23 5min Error
15 May 13:06 15 May 13:09 3min Error
12 May 13:06 12 May 13:16 10min Error

SYD1

Start Time End Time Down Info
15 May 13:28 15 May 14:09 41min Error
15 May 12:46 15 May 13:22 36min Error
15 May 12:35 15 May 12:41 6min Error

NS1

Start Time End Time Down Info
15 May 13:28 15 May 14:09 41min Error
15 May 12:35 15 May 13:22 47min Error

NS2

Start Time End Time Down Info
15 May 13:29 15 May 14:10 41min Error
15 May 13:06 15 May 13:23 17min Error

PL1.SYD

Start Time End Time Down Info
16 May 02:53 16 May 02:54 1min Error
16 May 01:04 16 May 01:05 1min Error
15 May 12:35 15 May 14:09 1hr 34min Error

PL2.SYD

Start Time End Time Down Info
15 May 13:28 15 May 14:10 42min Error
15 May 12:35 15 May 13:22 47min Error

UpTime Server

Start Time End Time Down Info
15 May 13:28 15 May 14:10 42min Error
15 May 12:35 15 May 13:22 47min Error
Please find below the original status log of what happened:

15/05/2026 12:51

There is a current issue with the Next DC Syd 1 location. We are waiting for onsite technicians to investigate and resolve 

15/05/2026 13:11

The issue appears to be related to network connectivity outside of the data centre.

At this stage, it appears to be a super loop networking fault.

This issue is affecting multiple hosting providers, not just UpTime.

15/05/2026 14:30

Remote monitors are reporting that external connections are coming back online.  There may be DNS-related issues if you still don't have access. Try rebooting your device and router.

We're waiting on official confirmation of what the actual issue was and will report that here once we have more information.

15/05/2026 15:15

The current outage has been caused by a large-scale distributed denial-of-service attack routed through the Superloop network. This attack was not targeted at UpTime specifically, but our upstream provider. This has caused outages across the country and has also affected other service and hosting providers.

This is not an intrusion attack but a network attack. No data is at risk from this attack

Our upstream provider is working on rerouting traffic, and we are seeing more services coming back online.

15/05/2026 18:50

All servers and service connections are now back online.

To confirm that all servers were online during this outage. It was the connection to them that was the issue.

Any emails sent to your accounts will be delivered over the next few hours.

We are continuing to monitor the situation, but expect everything to be resolved now.

« Back