SiteHost Outage History

Started Oct 20, 2026, 01:07 AM UTC· resolved Oct 20, 2026, 02:39 AM UTC

1. investigating Oct 20, 2026, 01:07 AM UTC

   The team are currently investigating a hardware issue on an internal hardware node which is impacting the SiteHost website, our Knowledge Base and some supplemental services such as paste.sitehost.nz. If you need to access the SiteHost control panel you should still be able to access it via cp.sitehost.nz

2. monitoring Oct 20, 2026, 02:30 AM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Oct 20, 2026, 02:39 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 26, 2026, 06:57 PM UTC· resolved Sep 27, 2026, 12:28 AM UTC

1. identified Sep 26, 2026, 06:57 PM UTC

   We have seen some intermittent connectivity issues to some of our services in the FRA01 data center and we are closely monitoring the situation with our upstream providers.

2. monitoring Sep 26, 2026, 07:21 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Sep 27, 2026, 12:28 AM UTC

   Our providers have stated that everything is at full operation in FRA01 and our monitoring shows a stable connection.

Read the full incident report →

Started Sep 25, 2026, 01:54 AM UTC· resolved Sep 25, 2026, 05:18 AM UTC

1. identified Sep 25, 2026, 01:54 AM UTC

   Our upstream provider InternetNZ has identified an issue at their end impacting multiple registrars. They have a status page up here with more information: https://status.internetnz.nz/incidents/mw4lt67vz5t4 This affects domain registrations, renewals, transfers, and WHOIS lookups.

2. monitoring Sep 25, 2026, 02:42 AM UTC

   InternetNZ have said a fix has been applied, they are monitoring system transactions and zone generations.

3. resolved Sep 25, 2026, 05:18 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 21, 2026, 09:20 PM UTC· resolved Sep 21, 2026, 11:29 PM UTC

1. investigating Sep 21, 2026, 09:20 PM UTC

   We're investigating an issue affecting all .nz domains. Registrations, renewals and transfers are currently unavailable. We'll update this notice as soon as we know more.

2. investigating Sep 21, 2026, 09:20 PM UTC

   We are continuing to investigate this issue.

3. identified Sep 21, 2026, 10:01 PM UTC

   Our upstream supplier InternetNZ has identified an issue at their end impacting multiple registrars. We're in contact with them and are awaiting a resolution (https://status.internetnz.nz/incidents/0lpv5xvhd2wr)

4. monitoring Sep 21, 2026, 10:22 PM UTC

   InternetNZ have implemented a fix and .nz functionality has been restored. We'll continue monitoring closely, but registrations, renewals and transfers should all be working correctly now.

5. resolved Sep 21, 2026, 11:29 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 15, 2026, 02:12 AM UTC· resolved Sep 15, 2026, 03:40 AM UTC

1. identified Sep 15, 2026, 02:12 AM UTC

   We've identified a hardware issue with the NZ-AKL1-V0P385 node, and we're performing an emergency shutdown. Servers on this hardware node will be unavailable during this time. For any emergency queries please email us at [email protected]

2. monitoring Sep 15, 2026, 02:42 AM UTC

   We've identified a faulty component in the hardware node and it's been replaced. Servers on this node should be coming back online now, and we are continuing to monitor the situation. If you're still experiencing issues please email us at [email protected]

3. resolved Sep 15, 2026, 03:40 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 06, 2026, 11:08 PM UTC· resolved Sep 06, 2026, 11:33 PM UTC

1. investigating Sep 06, 2026, 11:08 PM UTC

   We are currently experiencing delays in receiving support tickets. Our team is aware and working to resolve this as quickly as possible. Please be assured that your existing services are unaffected, customer servers, websites and email are operating normally. For urgent issues, please call us: 0800 484 537

2. resolved Sep 06, 2026, 11:33 PM UTC

   We have identified and fixed the issue and the tickets are now being delivered normally.

Read the full incident report →

Started Jul 06, 2026, 03:30 AM UTC· resolved Jul 06, 2026, 04:07 AM UTC

1. identified Jul 06, 2026, 03:30 AM UTC

   We're currently experiencing upstream network issues between SiteHost and overseas data centres that may be impacting some customers. Our team is investigating and we will post more information as it comes available.

2. monitoring Jul 06, 2026, 03:40 AM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jul 06, 2026, 04:07 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 30, 2026, 05:56 PM UTC· resolved Jul 01, 2026, 01:44 AM UTC

1. investigating Jun 30, 2026, 05:56 PM UTC

   We are aware of an issue with the US-CAL1-93PN5L hardware node affecting guests. Our engineers are currently investigating the issue and working to get this back up as soon as possible.

2. monitoring Jun 30, 2026, 06:50 PM UTC

   All servers are back up and running on the affected node and we are continuing to monitor for further issues.

3. resolved Jul 01, 2026, 01:44 AM UTC

   The node and guests have remained stable and we will continue to monitor for further issues. If you are still having issues with a guest on this node please get in touch at [email protected].

Read the full incident report →

Started Jun 18, 2026, 01:51 AM UTC· resolved Jun 18, 2026, 03:20 AM UTC

1. investigating Jun 18, 2026, 01:51 AM UTC

   We are aware of an issue with the NZ-AKL1-VEPQQR hardware node affecting guests. Our engineers are currently investigating the issue and working to get this back up as soon as possible.

2. monitoring Jun 18, 2026, 02:45 AM UTC

   All servers are back up and running on the affected node and we are continuing to monitor for further issues.

3. resolved Jun 18, 2026, 03:20 AM UTC

   The node and guests have remained stable and we will continue to monitor for further issues. If you are still having issues with a guest on this node please get in touch at [email protected].

Read the full incident report →

Started May 29, 2026, 12:56 AM UTC· resolved Jun 10, 2026, 12:03 AM UTC

1. investigating May 29, 2026, 12:56 AM UTC

   We’re currently investigating an issue affecting customers using Starlink internet connections who are unable to reach our services. Our monitoring shows that traffic from Starlink networks is not currently being correctly routed to our infrastructure, which is preventing normal connectivity. This appears to be a routing issue outside of our direct control. Our network team is actively investigating possible mitigation and working with upstream networks to restore normal access as quickly as possible. Customers using other internet providers are not affected at this time. We will provide further updates as more information becomes available.

2. monitoring Jun 03, 2026, 03:18 AM UTC

   Starlink has confirmed a routing adjustment on their side to resolve an issue that was impacting connectivity to our services. Their traffic is now being directed via an alternate path, and initial monitoring shows restored access. We are continuing to monitor the situation closely to ensure stability. If you continue to experience issues from Starlink connections, please let us know.

3. identified Jun 05, 2026, 01:01 AM UTC

   The routing issue with Starlink has recurred. Starlink customers based in the South Island are currently unable to access services hosted on our network. This is a routing issue outside of our control. We recommend that affected users raise this with Starlink. We're continuing to reach out to them directly, and our networking team are investigating what mitigations we can take from our end. In the meantime, we'd advise affected users to use a VPN or another internet connection as a workaround. Sites behind a CDN such as Cloudflare should be unaffected by this issue.

4. monitoring Jun 06, 2026, 09:37 PM UTC

   Starlink has made further adjustments on their end and customers are reporting a stable connection throughout the night. We are monitoring the situation closely and are working with Starlink and our upstream providers to reduce the likelihood of this recurring. If you are still experiencing connectivity issues please let us know.

5. resolved Jun 10, 2026, 12:03 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 25, 2026, 06:08 AM UTC· resolved May 25, 2026, 09:28 PM UTC

1. investigating May 25, 2026, 06:08 AM UTC

   We have experienced an unplanned network outage affecting our customers in the AKL02 region. Our engineers are currently investigating. We will share additional updates as we have more information.

2. monitoring May 25, 2026, 06:28 AM UTC

   The services have now been restored and we are actively monitoring the situation. If you have any persistent issues, please contact [email protected]

3. investigating May 25, 2026, 07:16 AM UTC

   We have experienced another network outage affecting our customers in the AKL02 region. Our engineers are currently investigating this outage. We will share additional updates as we have more information.

4. monitoring May 25, 2026, 10:11 AM UTC

   The services have now been restored and we are actively monitoring the situation. If you have any persistent issues, please contact [email protected]

5. resolved May 25, 2026, 09:28 PM UTC

   Monitoring over the past few hours has confirmed this specific AKL02 network issue is resolved.

Read the full incident report →

Started May 25, 2026, 12:02 AM UTC· resolved May 27, 2026, 10:06 PM UTC

1. investigating May 25, 2026, 12:02 AM UTC

   We are currently experiencing a Distributed Denial of Service (DDoS) attack affecting parts of our infrastructure. Our team is actively investigating the situation and implementing mitigation measures to minimise any impact on services. Some customers may experience intermittent connectivity issues, increased latency, or temporary service disruptions while mitigation efforts are underway. We will continue to provide updates as more information becomes available.

2. investigating May 25, 2026, 12:31 AM UTC

   We are continuing to investigate this issue.

3. investigating May 25, 2026, 01:13 AM UTC

   We are working with our upstream provider to adjust DDoS protection settings and optimise mitigation measures. During this time, some customers may experience intermittent interruptions or degraded performance. We will continue to monitor the situation and provide updates as progress is made.

4. investigating May 25, 2026, 01:48 AM UTC

   Services are currently operating normally for traffic routed within New Zealand. However, international traffic continues to experience degraded performance. Websites utilising CDNs or services hosted outside New Zealand may be intermittently affected, and external monitoring systems may incorrectly report affected services as unavailable. We continue to work with our upstream provider on mitigation efforts.

5. identified May 25, 2026, 02:40 AM UTC

   We have applied a mitigation on the network in Sydney to address the current issue and services should now be stabilising. If you continue to experience any issues with services or applications hosted with us, or if you are aware of any UDP traffic to or from your server, please contact our support team at [email protected].

6. identified May 25, 2026, 03:27 AM UTC

   We are still observing degraded performance across some services in all regions. We are actively working with our upstream providers to investigate and resolve the issue. We will continue to monitor the situation closely and provide further updates as more information becomes available.

7. identified May 25, 2026, 05:05 AM UTC

   We have applied a mitigation and websites/services that are not routed through Cloudflare should now be stabilising. We are still seeing degraded performance for some websites and services behind Cloudflare on certain networks and are continuing to investigate. We will provide further updates as more information becomes available. If you are still facing issues, please contact us at [email protected]

8. investigating May 25, 2026, 07:59 AM UTC

   We are continuing to experience service disruption related to ongoing issues between Cloudflare and SiteHost. Our team is actively working with our upstream providers to mitigate the impact and restore normal service as quickly as possible. For customers who use Cloudflare, we strongly encourage you to log a support ticket directly with Cloudflare and raise this issue with them. This will help bring the issue to Cloudflare’s attention and allow them to provide further technical details, which will assist us in working toward a faster resolution. You may also provide Cloudflare with our contact email address [email protected] so their team can reach out to us directly for coordination. Additionally, if you encounter network issues to our servers, please provide us with your IP address and traceroute to and from the server to your local network and forward to [email protected]. We apologise for the inconvenience and appreciate your patience while we continue working toward a resolution.

9. identified May 25, 2026, 10:18 AM UTC

   Our upstream providers have implemented additional mitigation measures to help address the ongoing issue. While these changes have improved overall service stability, some legitimate traffic may be impacted as a result. If you are experiencing issues with your websites, applications, or servers, please contact our support team. We can work directly with you to identify any affected traffic patterns and make any necessary adjustments to restore normal operation. We appreciate your patience and will continue to provide updates as the situation evolves.

10. identified May 25, 2026, 04:16 PM UTC

    Service in New Zealand remains stable, however we are still noticing impact due to the DDoS attack upstream internationally. We are still working with our upstream providers to implement mitigations. We have additional engineers working 24/7. If you need assistance, please drop us an e-mail and we will do our best: [email protected]

11. identified May 25, 2026, 09:34 PM UTC

    While general service levels continue to gradually improve we are still seeing ongoing impact from the DDoS attack, and we are working closely with our upstream providers to improve stability and connectivity. If you are experiencing issues please email support with your IP address and a traceroute to and from the server to your local network to assist is in troubleshooting. Thank you for your patience and support during this incident.

12. monitoring May 25, 2026, 11:16 PM UTC

    While we continue to monitor the situation closely, customer websites and servers appear to be stable at the moment. If you're still experiencing issues, please get in touch and include your IP address, a traceroute to the affected server, and steps to reproduce the issue.

13. monitoring May 26, 2026, 05:49 AM UTC

    All infrastructure has continued to be stable since our prior update, but engineers will continue monitoring closely overnight.

14. resolved May 27, 2026, 10:06 PM UTC

    All infrastructure has remained stable and we're now marking this incident as resolved. We're working on a full incident report that will be posted here in the coming days.

15. postmortem May 29, 2026, 03:52 AM UTC

    # DDoS Attack Incident Report On Monday 25 May, SiteHost received a ransom demand. This came from an actor using the name "BlackMatter" who had taken the time to sign up for an account with us. They demanded a nominal amount of Monero cryptocurrency, threatening a massive DDoS attack if we didn't pay. We had 15 minutes. We declined. Just before midday, the attack began. What follows is the detailed account of what happened, what we did about it and what we’ve learned. Some details may be a bit vague where we have opted to protect sensitive information, for ourselves or our upstream providers. ## Why didn't we pay the ransom demand? We refused for three primary reasons: 1. Paying provides no guarantee the attack will stop, or that a new demand won't follow. 2. Capitulating to extortion helps fund further attacks against us and others. 3. The New Zealand government [strongly discourages cyber-ransom payments](https://www.dpmc.govt.nz/our-programmes/national-security/cyber-security-strategy/cyber-ransom-advice). We would make the same decision again. ## What actually happened? Typically a DDoS attack will originate from a large number \(typically millions\) of compromised devices targeting a single or perhaps a small number of targets. We have blogged previously about how we would work with you if [you are targeted by a DDoS attack](https://sitehost.nz/blog/how-we-deal-with-ddos-attacks). In this instance, the specific target was us, SiteHost. We saw a sudden surge in traffic to effectively every single network address on our network. Individually the volume of traffic was not insurmountable, but combined it overwhelmed a number of our, and our upstream providers’, safeguards. ## Timeline \(NZST\) ### Monday 25 May * **11:52** — A DDoS attack was detected via monitoring alerts. Our network team opened an incident meeting within minutes and began working to identify which specific IPs were being targeted. Traffic volumes were substantial across our entire IP address space. * **12:05** — Our network engineers struggled to identify any clear patterns in the traffic when compared to a traditional DDoS attack. * **12:09** — First calls to upstream transit providers to coordinate mitigation. * **12:30** — We confirmed that the source of the traffic was widely distributed, across our entire network and coming in via a large number of remote IPs and networks. This ruled out simple edge blocking as a solution. * **13:00** — Mitigation applied to our network. We attempted to block traffic for unused IP space to reduce the attack surface. This was ineffective due to the sheer volume of traffic. * **13:15** — We began working with our upstream providers to adjust DDoS protection settings and engage scrubbing services. While our providers had DDoS scrubbing capability, the nature of the attack made it difficult for their systems to effectively distinguish attack traffic from legitimate traffic. * **13:30** — To get additional upstream support we engaged our secondary provider to assist. They immediately sprung into action creating their own incident response meeting with over 25 engineers, which we joined. * **13:50** — We dropped peering sessions that were contributing to large volumes of international \+ unfiltered traffic being routed to our network via local Internet Exchanges \(IXPs\). Services routed within New Zealand stabilised. * **14:15** — We called the National Cyber Security Centre \(NCSC\) for coordination and assistance. They committed to following up via email and a return call, though immediate solutions were limited. * **~14:30** — We further refined our traffic filtering, blocking non-essential UDP traffic. Some services began stabilising, however our upstream networks were still under load and experiencing high packet loss across their networks. * **~15:00** — We rerouted all Sydney transit traffic through Auckland and isolated our network to our secondary provider to utilise enhanced scrubbing capabilities. * **~15:30** — Degraded performance persisted across some parts of our network in both Australia and New Zealand. DDoS scrubbing services are still struggling with the attack. * **~16:00** — We continued with our upstream provider to find ways to improve stability to both our network and theirs. It was agreed to bring online additional scrubbing capacity from a provider further upstream. * **~16:30** — Additional DDoS scrubbing capacity is brought online further upstream. This is a complex change which requires an on the fly network reconfiguration to achieve. Traffic volumes to our network are greatly reduced for the first time in 4 hours. * **~17:00** — Further tuning of DDoS mitigations takes place, and our team is now primarily focused on feedback from our customers and implementing custom mitigations where possible. * **~17:30** — We identified that the additional scrubbing is causing significant disruption for certain sites. This depended on originating ISP and what Cloudflare node the traffic was routed through. Engineers suspect our control plane in one region has been overwhelmed due to the sheer volume of traffic. Direct server access remains functional, suggesting the issue was in the path between Cloudflare and our infrastructure. We are unable to see this path, making troubleshooting very difficult. * **17:56** — An unplanned network outage hits our AKL02 region. While troubleshooting the above issues, our network engineers attempt to clear the control plane on a fully drained switch which resulted in a switch reload. This should not normally cause a problem, but in this instance it boots without a valid config, creating a loop in the network. This results in a total outage in AKL02. * **18:05** — After identifying this was a hardware issue an engineer is dispatched to AKL02 with a replacement network device. * **~18:30** — AKL02 services restored. The faulty switch is removed from the rack, and a new switch is being installed. We continue monitoring AKL02. * **19:03** — AKL02 experienced a second outage. The control plane instability was persistent, and while trying to repair the network the active switch failed. * **19:20** — Engineers stabilise the AKL02 switch and service is restored. * **~20:00** — We identify a workaround for sites impacted by the specific Cloudflare network path issue above, but it requires manual configuration changes on a per customer basis. Our team starts working with individual customers who have contacted us and for whom the workaround is viable. Some ISPs such as Spark routed traffic remain largely unaffected, likely confirming the issue involves specific paths between ISPs, Cloudflare nodes, and our network. * **~21:00** — Mitigations and improvements continue to be made across our own and upstream networks. Our team continues trying to identify ways we can improve the current DDoS scrubbing which, while keeping our network protected from the attack, comes at the cost of a high false positive rate. * **~22:00** — The faulty AKL02 distribution has been replaced. Redundancy is fully restored. We continue to work with upstream providers and Cloudflare to obtain better visibility of the issues customers are seeing. ### Tuesday 26 May * **~01:00** — With a mitigation available for customers behind Cloudflare we believe we have resolved the highest priority issues. Our engineers are exhausted and their ability to troubleshoot further solutions is severely impaired. We make the call to stand down our New Zealand team, with our overseas teams taking over supporting our customers for the next few hours. * **~06:30** — Our New Zealand team gathers again and starts investigating options for outstanding issues. * **~08:30** — A meeting with our upstream network providers is scheduled for 09:30 to discuss remaining issues. * **~09:30** — Attack volumes significantly subside allowing us to apply further tuning to the DDoS scrubbing on our network and with our upstream providers. Services from all locations and network paths gradually return to normal. * **~11:00** — Services remain stable. We continued close monitoring and kept the status page incident open as a precaution. The incident will rightly raise a few questions, and we have done our best to answer some below. _**Don’t you have protection for this?**_ We do. This is the first time we have experienced a sustained and targeted attack like this. The attack was spread across our entire network and this event tested our upstream providers' capabilities as well. _**What are you going to improve or do differently in the future?**_ Unlike a specific hardware issue, or unsuccessful failover, there are less obvious points of failure and easily identifiable improvements to make. There is also the additional factor, which of course is the group responsible for the attack. They opened an account with us, and are likely reading this report. For this reason it is difficult for us to be fully transparent about the changes we will make. However, we want to make sure our customers understand that we know there is room for improvement, and we will be taking multiple steps to improve our resilience to attacks like these. We can’t promise it won’t happen again, no infrastructure provider can, but we can promise we will learn and improve. _**Why did scrubbing make things worse for some traffic \(Cloudflare path\)?**_ DDoS protection by its nature is imperfect. The scrubbing systems are trying to rapidly differentiate between legitimate and illegitimate traffic and struggled with the scale of this attack. As many of these systems are upstream from us we have very limited control or opportunity to fine tune the filtering to suit our customer base.While these protections kept us partially online, there are a number of areas we have identified where we think improvements can be made, and give us more agency in these situations. _**Why was my site impacted when others seemed fine?**_ The scrubbing systems affected some IP addresses based on a set of criteria that is not transparent to us and we do not have the ability to investigate every single scenario. Simply put: DDoS scrubbing is an imperfect service and while there is room for improvement here, it did very well considering the nature and volume of the attack. _**Was my server, data, account, or customer data at risk at any point?**_ No customer data or internal systems were at risk during this attack. _**Why did your AKL02 switches fail? Isn't that on you, not the attacker?**_ Yes, this is on us. We were attempting to move quickly to rule out issues and made a decision to perform emergency maintenance which went wrong. _**What stops this happening again next week, by the same or a copycat actor?**_ As much as we would like to say otherwise, nothing stops another attack of this nature, and globally they are getting more frequent and more aggressive. We can only learn from this and prepare for the next one. _**Are any fixes actually deployed, or still "planned"?**_ Both. Our priority at the start of the week has been to keep our customers online, and now our focus has shifted towards implementing a number of short term improvements which we have done and planning a number of larger improvements as part of what we learned on Monday. _**Should I put my site behind Cloudflare \(or move off it\) given what happened?**_ Cloudflare and other WAFs serve a purpose, and in many situations are helpful. However in an attack such as this they can make troubleshooting harder and sometimes near impossible. As with most things this is a tradeoff that only you can decide. _**Is there anything I should change my end — DNS, VPN config, failover region?**_ If you’re unsure you can always get in touch to discuss, and there are always options to make your sites and infrastructure more resilient. But in general, no, we don’t think action is required at your end as a direct result of this incident. _**Who do I contact next time, and how will you communicate updates?**_ We encourage customers to always [check our status page first](https://www.sitehost-status.net/) \(sitehost-status.net\) and if possible to subscribe for updates. This is our single, official channel for communicating during incidents like this. ## Final thoughts DDoS attacks of this nature are, unfortunately, a reality of operating internet infrastructure. This was the most significant attack we've experienced in 22 years of business, and the cascading effects, particularly the network control plane saturation and the interaction between scrubbing services and legitimate traffic \(particularly Cloudflare\), made it far more complex than a straightforward volumetric event against a single target. We are genuinely grateful for the patience and support our customers showed throughout the incident. Several of you sent messages of encouragement \(and doughnuts\) while our team worked through the night. It meant a lot. Lastly, I would like to say a huge thank you to the entire SiteHost team who went above and beyond during this incident. It was a true collective effort across the entire business, putting our customers first and upholding our already high support standards under what can only be described as challenging circumstances. To our partners, your support during this time truly embodied what it means to see kiwi businesses backing each other. Thank you. If you have any questions about this incident, please don't hesitate to reach out to us at [[email protected]](mailto:[email protected]). — Quintin ‌ ‌ ‌ ‌ #### Glossary UDP \(User Datagram Protocol\) _A connectionless network protocol. Unlike TCP \(Transmission Control Protocol\), UDP does not establish a session before sending data, which makes it fast but can also be easier for attackers to abuse._ DDoS \(Distributed Denial of Service\) _An attack that floods a target with traffic from many different sources at once. The goal is to overwhelm the target so legitimate traffic cannot get through._ Scrubbing _A mitigation technique where traffic is routed through a filtering service. The service inspects the traffic, and attempts to drop the attack packets, and forward the legitimate traffic on to its destination._ Upstream Provider _The network provider that connects our network to the wider internet. Our traffic to and from customers passes through their infrastructure, so they sit between us and most external networks._

Read the full incident report →

Started Mar 19, 2026, 11:47 PM UTC· resolved Mar 20, 2026, 02:15 AM UTC

1. investigating Mar 19, 2026, 11:47 PM UTC

   We are aware of an issue with the NZ-AKL1-6O53ER hardware node affecting guests. Our engineers are currently investigating the issue and working to get this back up as soon as possible.

2. identified Mar 20, 2026, 12:53 AM UTC

   We’ve identified a hardware issue affecting the node and are currently in the process of replacing the faulty component. Our engineering team is actively working to restore services as quickly as possible.

3. monitoring Mar 20, 2026, 01:25 AM UTC

   The faulty hardware component has been replaced, and the node has been brought back online. All servers on the affected node are now operational, and we are continuing to monitor the environment closely for any further issues. Please don't hesitate to reach out if you notice any issues.

4. resolved Mar 20, 2026, 02:15 AM UTC

   The hardware node and associated services have remained stable. We will continue to monitor the situation closely. If you experience any further issues with a server on this node, please contact us at [email protected]

Read the full incident report →

Started Feb 02, 2026, 04:04 PM UTC· resolved Feb 02, 2026, 08:17 PM UTC

1. identified Feb 02, 2026, 04:04 PM UTC

   We are aware of ongoing issues with our DNS services due to denial of service attack. We are working to mitigate the issues. This service degradation may result in intermittent issues resolving services that are using SiteHost DNS servers on or outside of our network.

2. monitoring Feb 02, 2026, 06:46 PM UTC

   We have implemented some mitigations and the DNS service appears to now be stable. If you are experiencing ongoing issues with SiteHost DNS resolution please get in touch.

3. resolved Feb 02, 2026, 08:17 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 25, 2025, 08:02 PM UTC· resolved Dec 25, 2025, 11:40 PM UTC

1. investigating Dec 25, 2025, 08:02 PM UTC

   We are aware of a networking issue at present that is affecting traffic to our California Data Center (CAL01), this could lead to degraded connectivity or increased latency for servers located in CAL01. We are working with our upstream providers to get this resolved.

2. monitoring Dec 25, 2025, 10:38 PM UTC

   A fix has been implemented and we are monitoring the results.

3. monitoring Dec 25, 2025, 10:38 PM UTC

   We are continuing to monitor for any further issues.

4. resolved Dec 25, 2025, 11:40 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 27, 2025, 09:36 PM UTC· resolved Nov 27, 2025, 10:05 PM UTC

1. investigating Nov 27, 2025, 09:36 PM UTC

   Currently, we are experiencing an outage on some internal hardware nodes, which is affecting our website, knowledge base, API documentation, and other services. Engineers are actively working on resolving the issue. No customer servers, containers, or websites are impacted and our Control Panel and API are working as expected.

2. monitoring Nov 27, 2025, 09:52 PM UTC

   We have restored the nodes and all of our impacted services are back online. We're monitoring the health of the nodes and conducting further investigations.

3. monitoring Nov 27, 2025, 10:01 PM UTC

   We are continuing to monitor for any further issues.

4. resolved Nov 27, 2025, 10:05 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 18, 2025, 12:52 PM UTC· resolved Nov 18, 2025, 07:31 PM UTC

1. identified Nov 18, 2025, 12:52 PM UTC

   We are aware of an issue with Cloudflare. They are investigating issues with their services and/or network. More details on this can be found here: https://www.cloudflarestatus.com/

2. monitoring Nov 18, 2025, 02:46 PM UTC

   We have observed the fix that has been rolled out by Cloudflare is propagating. We are actively monitoring the situation. If you are still experiencing any issues please reach out to us on [email protected]

3. resolved Nov 18, 2025, 07:31 PM UTC

   Cloudflare have indicated that their services are considered stable. For further information, please see the Cloudflare status page for the event: https://www.cloudflarestatus.com/incidents/8gmgl950y3h7

Read the full incident report →

Started Oct 23, 2025, 11:51 AM UTC· resolved Oct 23, 2025, 12:47 PM UTC

1. investigating Oct 23, 2025, 11:51 AM UTC

   We are aware of an issue with our high performance hardware nodes in FRA01 affecting guests. Our engineers are currently investigating the issue and working to get this back up as soon as possible.

2. monitoring Oct 23, 2025, 12:13 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Oct 23, 2025, 12:47 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 24, 2025, 08:30 PM UTC· resolved Sep 24, 2025, 10:55 PM UTC

1. identified Sep 24, 2025, 08:30 PM UTC

   We have experienced some hardware node instability issues with one of the nodes (NZ-AKL2-6O20W9). As a result, we need to perform emergency maintenance to reduce the likelihood of future issues. This will involve rebooting the servers on this node.

2. monitoring Sep 24, 2025, 08:57 PM UTC

   We have completed the emergency maintenance and are currently monitoring the situation. All services hosted on the node should be restored.

3. resolved Sep 24, 2025, 10:55 PM UTC

   The node and guests have remained stable and we will continue to monitor for further issues. If you are still having issues with a guest on this node please get in touch at [email protected].

4. postmortem Sep 24, 2025, 10:59 PM UTC

   **Summary** This morning **at 8:30 AM**, one of our monitoring systems alerted us to a problem with the storage service on a node. This caused disruption for the virtual machines \(VMs\) running on that hardware. **Timeline** * **8:30 AM** – Monitoring detected the issue. * **8:45 AM** – Our team determined a reboot was the fastest way to restore service. * **8:55 AM** – The node was rebooted and VMs began coming back online. * **11:00 AM** – Services confirmed stable; incident closed. **Cause** The disruption was traced to a **faulty hard drive** in the storage system. **Resolution** The faulty drive was removed and replaced. The storage service has remained stable since, and no further issues are expected. **Next Steps** We are improving monitoring and alerting to catch early signs of drive degradation sooner, helping us prevent similar issues in the future. **Current Status** All services are fully operational.

Read the full incident report →

Started Aug 14, 2025, 08:09 AM UTC· resolved Aug 14, 2025, 01:39 PM UTC

1. identified Aug 14, 2025, 08:09 AM UTC

   We’ve had a hardware failure on one of our core distribution switches in the AKL01 data centre. To restore full network redundancy and capacity, we’ll be carrying out emergency maintenance tonight at 11:00 PM NZST. We’re not expecting downtime, but you may notice brief periods of higher latency or reduced performance during the work. If you experience any issues accessing services, please contact us at [email protected].

2. monitoring Aug 14, 2025, 11:36 AM UTC

   The core network issue in the AKL01 data centre has been resolved and full redundancy has been restored. We are actively monitoring the network to ensure stability and normal performance.

3. resolved Aug 14, 2025, 01:39 PM UTC

   The core network issue in the AKL01 data centre has been fully resolved. Services have remained stable, and monitoring confirms normal performance. If you experience any issues accessing services, please contact us at [email protected].

Read the full incident report →

Started Jul 21, 2025, 10:23 PM UTC· resolved Jul 22, 2025, 05:55 AM UTC

1. identified Jul 21, 2025, 10:23 PM UTC

   We have become aware of an issue affecting automated SSL renewal/issuance on Cloud Containers and Servers that are using LetsEncrypt. They are currently dealing with the incident and we will be monitoring the status and keeping you posted as the situation develops.

2. monitoring Jul 22, 2025, 03:13 AM UTC

   LetsEncrypt has implemented a fix which means certificate renewals should start working again. Keep in mind that they are experiencing higher than average traffic volumes so there may still be some delays in certificate renewal/issuing.

3. resolved Jul 22, 2025, 05:55 AM UTC

   All of our services appear to be operating correctly, LetsEncrypt is currently monitoring the status of their API.

Read the full incident report →

Started Jun 27, 2025, 03:09 AM UTC· resolved Jul 06, 2025, 09:33 PM UTC

1. monitoring Jun 27, 2025, 03:09 AM UTC

   We experienced intermittent network connectivity issues affecting guests hosted on node NZ-AKL1-6G2QEQ, starting around 1:00 PM. This was due to a targeted DDOS attack on the node, resulting in brief network flaps for some customers in the affected zone. The issue was mitigated, and as of 2:12 PM, network performance has returned to normal. We are continuing to monitor the situation closely to ensure ongoing stability. If you continue to experience any issues, please don’t hesitate to reach out to us at [email protected].

2. investigating Jun 27, 2025, 03:25 AM UTC

   We are seeing some network connectivity issues again. Our team is actively investigating and working to identify the source of this recurrence, which may be related to the earlier DDOS activity. We’ll provide further updates as we progress with mitigation. We appreciate your patience and understanding while we work to restore full stability.

3. monitoring Jun 27, 2025, 04:30 AM UTC

   Network performance has returned to normal. We are continuing to monitor the situation closely.

4. resolved Jul 06, 2025, 09:33 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 12, 2025, 10:38 PM UTC· resolved May 13, 2025, 01:40 AM UTC

1. identified May 12, 2025, 10:38 PM UTC

   We are aware of an ongoing DNS outage affecting domains configured with nameservers pointing to Freeparking. This is causing websites, email services, and other dependent systems to become inaccessible or unreliable. If you'd like to transfer your domains and DNS over to us, you can reach out to us at [email protected] for assistance.

2. monitoring May 12, 2025, 11:01 PM UTC

   DNS services for domains using Freeparking nameservers appear to be back online now. As this outage originated from Freeparking's infrastructure, it was outside our control. We are continuing to monitor the situation in case of any further disruptions.

3. resolved May 13, 2025, 01:40 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 06, 2025, 11:54 PM UTC· resolved Mar 07, 2025, 03:18 AM UTC

1. investigating Mar 06, 2025, 11:54 PM UTC

   We are aware of an issue affecting several of our hardware nodes in the AKL02 region, and are working to get this back up as soon as possible.

2. monitoring Mar 07, 2025, 01:24 AM UTC

   We've identified an issue with the power supply in one of our cabinets in the AKL02 datacentre. We've restored the services, but will be keeping a close eye on it.

3. resolved Mar 07, 2025, 03:18 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 26, 2025, 12:39 AM UTC· resolved Feb 26, 2025, 08:33 AM UTC

1. identified Feb 26, 2025, 12:39 AM UTC

   We are aware of an issue within the Spark network at present that is affecting traffic passing through Cloudflare towards our network for Spark customers. We are currently working with Cloudflare to help get this resolved but as the issue is within Spark's network we have limited remediation options at present. We recommend you contact Spark directly to help expedite a solution to the issues within their network. Alternatively, Cloudflare can temporarily be paused by following the steps: https://developers.cloudflare.com/fundamentals/setup/manage-domains/pause-cloudflare/

2. monitoring Feb 26, 2025, 04:24 AM UTC

   We believe this issue should be resolved, if you were affected please re-test now and contact our support team if you're still experiencing issues. Additionally, if you temporarily disabled Cloudflare because of this, it should now be safe to re-enable and test.

3. resolved Feb 26, 2025, 08:33 AM UTC

   This incident has been resolved.

Read the full incident report →