Cloudi-Fi Outage History

Started Aug 25, 2026, 01:00 PM UTC· resolved Aug 25, 2026, 04:41 PM UTC

1. identified Aug 25, 2026, 01:00 PM UTC

   An identified network incident is affecting our **radius 802.1x** service and should be soon resolved. As fallback and to make our radius availability more robust, we recommend our customers to update their 802.1x radius configuration to use these new DNS endpoints : * [radius-8021x-eu1.cloudi-fi.net](http://radius-8021x-eu1.cloudi-fi.net) * [radius-8021x-eu2.cloudi-fi.net](http://radius-8021x-eu2.cloudi-fi.net) Please make sure these Cloudi-Fi radius IPs are allowed on your firewalls (UDP/1815) : * 178.32.123.138 * 5.135.94.202 * 164.132.247.209 * 91.134.58.235.

2. resolved Aug 25, 2026, 04:41 PM UTC

   This network incident has been resolved, a faulty network device has been replaced. **If you use Cloudi-Fi 802.1x service, please make sure you update your configuration to use our new DNS endpoints.** We apologize for any inconvenience caused and appreciate your understanding..

Read the full incident report →

Started Jul 22, 2026, 03:30 PM UTC· resolved Sep 04, 2026, 02:20 PM UTC

1. investigating Jul 22, 2026, 03:30 PM UTC

   **Description of the Anomaly** When a device re-enters the captive portal flow while its previous session is still active, a new authentication token is generated for the same IP address and site instead of reusing the existing valid session. This behavior has contributed to the authentication delays observed by end users. **Investigation Status** Following investigation with Zscaler support, it was confirmed that the issue stems from latency in the backend infrastructure during authentication validation. In the test case analyzed, the response from [login.zscaler.net](http://login.zscaler.net) was delayed by approximately 28 seconds. This delay causes the captive portal browser on iOS and Android devices to time out before the authentication flow can complete. Although authentication is ultimately validated in the background, it occurs too late for the portal window to close as expected, resulting in a degraded experience for end users. **Action Plan** We continue to work closely with Zscaler support to determine the root cause of this backend latency and identify a permanent resolution. In the meantime, we have implemented a mitigation measure related to the authentication process: it will now be triggered less frequently, reducing how often guests encounter the 28-second delay. We will share further updates as soon as additional information becomes available..

2. resolved Sep 04, 2026, 02:20 PM UTC

   Following continued investigation with Zscaler support, the authentication flow has remained stable during repeated validation tests. The previously observed symptoms, including blank captive portal pages, authentication errors, and abnormal authentication delays, have not been reproduced during the latest tests. The service is therefore considered stable and the incident will now be closed. Should similar symptoms occur again, a new investigation will be initiated and the corresponding authentication traces will be collected for further analysis..

Read the full incident report →

Started Jul 21, 2026, 12:05 AM UTC· resolved Jul 21, 2026, 07:08 AM UTC

1. investigating Jul 21, 2026, 12:05 AM UTC

   **Incident Summary** We are facing an issue with the access to our captive portal in (APAC, Australia) region (login-cn.cloudi-fi.net) **Impact** Visitors from (APAC, Australia) region are getting an error page in the captive portal "Sorry, an error occured, Please contact Cloudi-Fi support team"

2. monitoring Jul 21, 2026, 12:12 AM UTC

   We implemented a fix and are currently monitoring the result.

3. resolved Jul 21, 2026, 07:08 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 10, 2026, 01:29 AM UTC· resolved Jul 10, 2026, 02:06 AM UTC

1. investigating Jul 10, 2026, 01:29 AM UTC

   We are currently investigating a service disruption affecting Cloudi-Fi. Users may experience issues accessing the captive portal, completing the authentication flow, or accessing the Admin interface. Our team is working to identify the root cause and restore normal service as quickly as possible. Further updates will be shared as soon as they become available.

2. identified Jul 10, 2026, 01:39 AM UTC

   The issue has been identified and is related to an ongoing incident affecting our hosting provider’s network infrastructure. A faulty network equipment component is currently impacting network connectivity on their side. Their teams are replacing the affected equipment to restore service as quickly as possible. We are closely monitoring the situation and will continue to provide updates as more information becomes available.

3. identified Jul 10, 2026, 02:02 AM UTC

   The captive portal is now operational again, and users should be able to access the portal and complete the authentication flow. Access to the Admin interface remains impacted at this stage. The Cloudi-Fi team is continuing to work on the incident and assess mitigation measures to restore full service as quickly as possible. Further updates will be shared as soon as more information becomes available.

4. resolved Jul 10, 2026, 02:06 AM UTC

   The incident has now been resolved. Access to the Admin interface has been restored, and the captive portal and authentication flow remain operational. The Cloudi-Fi team has completed the necessary checks and will continue to monitor the service to ensure stability. Thank you for your understanding.

5. resolved Jul 10, 2026, 02:17 PM UTC

   On July 9-10, 2026, from 23:51 UTC to 02:35 UTC, Cloudi-Fi experienced a service disruption caused by two hosting provider incidents affecting network equipment and VIP failover. * Impacted services: Captive portals, Admin interface, RADIUS EMEA (excluding 802.1x) * Not impacted services: DHCP, RADIUS 802.1x, RADIUS APAC Captive portal and Admin services were restored on July 10, 2026, at 02:00 UTC. RADIUS EMEA service was restored on July 10, 2026, at 02:35 UTC after the faulty network equipment was replaced. Cloudi-Fi applied mitigations, completed post-incident checks, and is reviewing infrastructure dependencies and incident handling improvements.

Read the full incident report →

Started Jun 30, 2026, 04:12 PM UTC· resolved Jun 30, 2026, 04:22 PM UTC

1. investigating Jun 30, 2026, 04:12 PM UTC

   We are currently investigating an issue affecting administrators using SSO links to access the Cloudi-Fi Admin interface. When opening an SSO link, administrators may receive a **500 Internal Server Error** and may be unable to access the Admin interface. Our technical team is actively investigating the issue and working to restore access. We apologize for the inconvenience caused.

2. identified Jun 30, 2026, 04:22 PM UTC

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

3. resolved Jun 30, 2026, 04:22 PM UTC

   The issue affecting administrators using SSO links to access the Cloudi-Fi Admin interface has been resolved. Administrators should now be able to access the Admin interface normally. The **500 Internal Server Error** is no longer observed. We apologize for the inconvenience caused and thank you for your patience.

Read the full incident report →

Started Apr 07, 2026, 02:15 AM UTC· resolved Apr 07, 2026, 04:15 PM UTC

1. investigating Apr 07, 2026, 02:15 AM UTC

   **Investigating: Service Issues with Zscaler Integration (APAC)** We are currently investigating reports of connectivity issues affecting customers integrated with the [**zscloud.net**](http://Zscloud.net) cloud in the **APAC region**. We are working directly with Zscaler to identify the cause and will provide updates as they become available..

2. identified Apr 07, 2026, 07:00 AM UTC

   **Monitoring: Investigation & Remediation in Progress** Zscaler has officially acknowledged our support ticket and is investigating the issue. Simultaneously, our internal engineering teams are evaluating potential remediation steps to restore service for **APAC customers**. We will share more details as our joint efforts progress..

3. identified Apr 07, 2026, 08:00 AM UTC

   **Monitoring: Expanded Scope & Investigation** Our investigation has confirmed that the impact extends beyond the [zscloud.net](http://Zscloud.net) environment to include [zscaler.net](http://zscaler.net) and other Zscaler clouds within the APAC region. Zscaler has acknowledged our high-priority ticket, and we are working closely with their team while our internal engineers continue to pursue a parallel remediation path..

4. identified Apr 07, 2026, 08:40 AM UTC

   **Monitoring: Multiple Impacted Nodes Identified (Singapore & Chennai)** Our ongoing investigation has confirmed that the issue is not limited to the Singapore node. We have identified that the Chennai 2 node (India) is also experiencing disruptions, contributing to the connectivity issues across the APAC region. ## **Recommended Workaround** To restore connectivity immediately, we suggest customers manually switch their traffic to one of the following stable nodes: * **Hong Kong 3** * **Tokyo 4** We continue to work with Zscaler to resolve the specific issue in Singapore and will provide a final update once the node is stabilized..

5. identified Apr 07, 2026, 11:00 AM UTC

   **Monitoring: Additional Impacted Node (Chennai 2) & Verified Workaround** Our ongoing investigation has confirmed that the disruption is not limited to Singapore. The Chennai 2 node (India) is also experiencing significant instability. We have successfully verified a workaround with impacted customers in the region. ## **Verified Workaround** If you are experiencing connectivity issues or tunnel drops on the affected nodes, please implement the following failovers: * **For India-based traffic (Chennai 2):** Redirect tunnels to the **Hyderabad 1** node. This has been confirmed to restore stable connectivity in live testing. * **For Singapore-based traffic:** Redirect to **Hong Kong 3** or **Tokyo 4**. We remain in constant communication with Zscaler support as they work toward a permanent fix for the Singapore and Chennai data centers..

6. identified Apr 07, 2026, 01:45 PM UTC

   **Monitoring: Expanded Impact to US Nodes & Escalation** The scope of this incident has broadened beyond the APAC region. We have now received reports of similar connectivity issues affecting Zscaler nodes in the US. We have escalated this matter to senior Zscaler engineering leadership for an urgent, comprehensive investigation into what appears to be a multi-region disruption. ## **Current Status & Workarounds** While we await a global resolution from Zscaler, please continue to utilize the previously verified node failovers: * **India:** Move from Chennai 2 to **Hyderabad 1**. * **APAC:** Move from Singapore to **Hong Kong 3** or **Tokyo 4**. * **US:** We are currently identifying stable target nodes for US traffic and will provide specific recommendations shortly. Our internal teams remain on high alert and are working alongside Zscaler to stabilize service globally..

7. monitoring Apr 07, 2026, 03:15 PM UTC

   **Monitoring: Global Mitigation Applied by Zscaler** Zscaler has implemented a global fix to address the connectivity issues affecting multiple nodes (including Singapore, Chennai 2, and US-based data centers). We have received initial confirmation from customers in both the **US and APAC regions** that service has been restored and they are now able to connect via their original primary nodes. Zscaler has also published an official update regarding this resolution on their Trust Portal: [Zscaler Status Post 28871](https://trust.zscaler.com/zscaler.net/posts/28871). We are waiting the RCA from Zscaler engineering team.

8. resolved Apr 07, 2026, 04:15 PM UTC

   ## **Incident Update: Resolved** **Resolved: Global Service Restoration** We have confirmed that service has been fully restored across all Zscaler clouds and regions, including the previously impacted nodes in **Singapore**, **Chennai 2**, and the **US**. Zscaler has implemented a global fix, and our internal telemetry shows that all integration traffic is now flowing normally. **Next Steps** Our engineering leadership is currently awaiting the formal **Root Cause Analysis (RCA)** from Zscaler’s engineering team. Once we have reviewed their technical breakdown of the multi-region disruption, we will provide a comprehensive summary to all affected customers..

9. monitoring Apr 14, 2026, 04:15 PM UTC

   # RCA From Zscaler: Incident Summary ● On April 7th, 2026, Zscaler received customer reports of Identity Provider (IdP)-initiated authentication failures affecting the [zscaler.net](http://zscaler.net) and [zscloud.net](http://zscloud.net) cloud environments. ● Customers using IdP-initiated authentication (notably Cloudi-Fi) experienced login failures (Error 581000 / 403 Forbidden) where the authentication redirect flow failed at the final redirect to [gateway.zscloud.net](http://gateway.zscloud.net), preventing users from accessing resources. ● Zscaler’s investigation determined the root cause was a recently enabled feature bit. Zscaler disabled the feature bit on the control plane for impacted cloud environments, and customers reported the issue was mitigated. ● On April 8th, 2026, additional reports were received. Zscaler confirmed the feature bit remained disabled on the control plane. However, further analysis found the disablement had not propagated to some Service Edges that form the data plane, resulting in continued impact for a subset of customers. ● Zscaler performed a full cloud audit to identify affected Service Edges and executed a Central Authority (CA) cache flush on impacted Service Edges to restore normal configuration synchronization. After the flush, the change propagated successfully, and service returned to normal. ● As part of Zscaler’s Post-Incident Review (PIR) process, Zscaler is evaluating monitoring, alerting thresholds, and resiliency controls to identify improvement opportunities and further reduce the likelihood and impact of similar events. This document contains preliminary findings; a final Root Cause Analysis (RCA) will be issued following validation of long-term corrective actions. # Incident Trigger ● A newly implemented security feature bit was introduced to enhance protections against open redirects during authentication handoffs. The feature validates redirect tokens and Zscaler private and confidential information targets to safeguard Zscaler’s service against abuse of open redirect paths in authentication redirect flows. ## Impact (Medium) ● Customers using IdP-initiated authentication (notably Cloudi-Fi) experienced login failures (Error 581000 / 403 Forbidden) where the authentication redirect flow failed at the final redirect to [gateway.zscloud.net](http://gateway.zscloud.net), preventing users from accessing resources. ## Incident Window | **Time (UTC)** | **Event** | | --------------------- | ----------------------------------------- | | April 7th, 2026 06:59 | Incident start (INC-000001256) | | April 7th, 2026 15:09 | Incident mitigated (feature bit disabled) | | April 8th, 2026 05:58 | Further impact reported (INC-000001257) | | April 8th, 2026 12:27 | Incident resolved (CA flush completed) | # Resolution Details ● Zscaler implemented corrective actions to resolve the incident. Zscaler disabled the feature bit on the control plane for the impacted cloud environments and completed a CA cache flush on impacted Service Edges to restore normal configuration synchronization. # Strategic Improvements ● As part of Zscaler’s Post-Incident Review (PIR) process, Zscaler is evaluating monitoring, alerting thresholds, and resiliency controls to identify improvement opportunities and further reduce the likelihood and impact of similar events. This document contains preliminary findings; a final Root Cause Analysis (RCA) will be issued following validation of long-term corrective actions..

Read the full incident report →

Started Apr 02, 2026, 08:00 AM UTC· resolved Apr 02, 2026, 08:00 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Apr 01, 2026, 07:00 PM UTC· resolved Apr 01, 2026, 07:00 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Mar 19, 2026, 01:00 PM UTC· resolved Mar 19, 2026, 01:00 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Mar 17, 2026, 05:34 AM UTC· resolved Mar 17, 2026, 07:02 AM UTC

1. investigating Mar 17, 2026, 05:34 AM UTC

   An incident has been identified where the DHCP Node is currently unavailable, impacting the Cloudi-Fi VPNs and the automatic assignment of IP addresses to connected devices. As a result, new devices may fail to connect, and existing sessions may experience disruptions. Our engineering team is actively investigating the root cause and working on remediation..

2. resolved Mar 17, 2026, 07:02 AM UTC

   The issue impacting the DHCP service has now been resolved. Devices are successfully receiving IP address allocations, and network connectivity has been restored. We have also confirmed that associated services, including VPN connectivity, are functioning normally. Our team will continue to monitor the environment to ensure stability. Thank you for your patience..

3. monitoring Mar 18, 2026, 11:10 AM UTC

   ### **Incident Summary** On 17 March 2026, an incident impacted a subset of dedicated servers hosted on a specific rack, resulting in temporary service unavailability for affected customers. The issue was identified, contained, and resolved within a short time window. ### **Timeline (UTC)** * **Start Time:** 05:35 UTC * **Incident Identified:** Shortly after detection, the issue was traced to a specific rack. * **Resolution Time:** 06:20 UTC * **Total Duration:** \~45 minutes ### **Impact Assessment** * **Affected Services:** Dedicated servers located on a specific rack. * **Customer Impact:** * Temporary loss of access to impacted servers * No data loss or security impact identified * **Scope:** Limited to servers within the specified rack; no broader infrastructure impact observed ### **Root Cause** The incident was caused by an **electrical equipment issue** affecting the power supply to the specified rack, resulting in temporary service disruption. ### **Detection & Response** * The issue was detected through monitoring alerts indicating service unavailability * Engineering teams promptly investigated and isolated the issue to the affected rack * Immediate remediation actions were initiated to restore power and stabilize affected systems ### **Resolution** * Power-related issues were addressed at the rack level * Systems were progressively restored and validated * Full service was confirmed restored by **06:20 UTC** ### **Preventive & Corrective Actions** To reduce the likelihood of recurrence, the following actions are being undertaken: * **Infrastructure Review:** Inspection and validation of electrical components associated with the affected rack * **Preventive Maintenance:** Reinforcement of periodic checks for power equipment across racks * **Monitoring Enhancements:** Improved alerting for early detection of power anomalies * **Operational Readiness:** Review of incident response procedures to ensure continued rapid resolution ### **Conclusion** The incident was contained within a limited scope and resolved promptly. We remain committed to maintaining high availability standards and are taking proactive measures to further strengthen infrastructure resilience. ---.

Read the full incident report →

Started Feb 09, 2026, 10:00 AM UTC· resolved Feb 09, 2026, 02:34 PM UTC

1. identified Feb 09, 2026, 10:00 AM UTC

   We detected an issue on our radius service. Devops team is looking at the issue..

2. monitoring Feb 09, 2026, 12:00 PM UTC

   We detected an intermittent issue affecting our radius service. A fix has been done and load-balancing have been implemented on our side to improve the stability. .

3. resolved Feb 09, 2026, 02:34 PM UTC

   This incident has been resolved. We apologize for any inconvenience caused..

Read the full incident report →

Started Jan 29, 2026, 08:00 AM UTC· resolved Jan 29, 2026, 08:00 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Jan 28, 2026, 03:00 PM UTC· resolved Jan 28, 2026, 03:00 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Jan 28, 2026, 08:00 AM UTC· resolved Jan 28, 2026, 08:00 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Jan 27, 2026, 11:45 PM UTC· resolved Jan 28, 2026, 03:05 AM UTC

1. investigating Jan 27, 2026, 11:45 PM UTC

   We are currently investigating an incident involving authentication lagging or looping on guest captive portals. Our development team is actively investigating..

2. identified Jan 28, 2026, 01:07 AM UTC

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

3. resolved Jan 28, 2026, 03:05 AM UTC

   **Incident Summary** Cloud-Fi was alerted to an issue registering guest users by multiple customers utilizing Captive Portal services. Our team quickly responded to this incident and applied emergency patching to resolve the issue. **Impact** Cloudi-Fi Captive Portal Customers.

Read the full incident report →

Started Jan 27, 2026, 08:00 AM UTC· resolved Jan 27, 2026, 08:00 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Jan 26, 2026, 04:30 PM UTC· resolved Jan 26, 2026, 04:30 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Dec 05, 2025, 08:50 AM UTC· resolved Dec 05, 2025, 10:51 AM UTC

1. identified Dec 05, 2025, 08:50 AM UTC

   Our support system has been impacted by the global issue on Cloudflare side. We are currently investigating this incident..

2. resolved Dec 05, 2025, 10:51 AM UTC

   Our support system is now working as expected. Cloudflare has provided an RCA. To know more: .

Read the full incident report →

Started Dec 02, 2025, 09:42 AM UTC· resolved Dec 02, 2025, 09:42 AM UTC

1. resolved Dec 02, 2025, 09:42 AM UTC

   **Impact:** We have identified that the DHCP service is facing issues, so some customers may experience: * DHCP service not responding as expected * Tunnel interfaces not coming up or appearing as unresponsive * Delays or failures in new configuration/application **Current actions:** * Core DHCP and related services have been restarted. * We are actively monitoring the provisioning tasks and tunnel interface status. * Additional diagnostics are in progress to ensure stability and prevent recurrence. **We can confirm that the DHCP service is now fully stable and functioning normally.**.

Read the full incident report →

Started Dec 02, 2025, 09:00 AM UTC· resolved Dec 02, 2025, 09:00 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Nov 18, 2025, 01:00 PM UTC· resolved Nov 19, 2025, 10:14 AM UTC

1. monitoring Nov 18, 2025, 01:00 PM UTC

   **Incident Summary** We are providing an update on the ongoing intermittent service degradation impacting Cloudi-Fi services, which is caused by a major incident on the Cloudflare Global Network. **Impact** Cloudi-Fi Services: Customers may continue to experience intermittent connectivity issues, higher latency, and connection errors (e.g., 5xx errors) when accessing or using Cloudi-Fi services globally. Root Cause: External service degradation affecting our infrastructure provider, Cloudflare. Latest Cloudflare Status (Last Update: 12:53 UTC) Cloudflare is continuing to investigate the internal service degradation affecting their global network. While they previously reported seeing services recover, the status remains in the Investigation/Remediation phase, indicating the issue is not yet fully resolved. **Next Steps** The Cloudi-Fi team remains on high alert and is strictly monitoring the stability of the Cloudflare network. Our services will restore full stability automatically as Cloudflare completes their remediation efforts. We will not post a new status until we receive a material update from Cloudflare or observe a significant change in the Cloudi-Fi service recovery. **Workaround** Our team has bypassed the Cloudflare service at this moment to make our services back to normal..

2. resolved Nov 19, 2025, 10:14 AM UTC

   The Cloudflare major incident is now resolved so re-enabling it on our services and everything back to normal..

Read the full incident report →

Started Nov 03, 2025, 08:03 AM UTC· resolved Nov 03, 2025, 08:13 AM UTC

1. investigating Nov 03, 2025, 08:03 AM UTC

   **Incident Description:** An issue has been identified where the Device section (Admin UI > Network > Devices) displays a “Network Error” message. This prevents users from viewing or managing devices within the platform. The error occurs during attempts to load device-related data. **Impact**: Users are unable to access or manage device information. The rest of the services (Mac-based Authentication and DHCP) are functioning properly. **Actions Taken / Next Steps:** Our development team is investigating the issue and checking the relevant components..

2. monitoring Nov 03, 2025, 08:08 AM UTC

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

3. resolved Nov 03, 2025, 08:13 AM UTC

   **Incident Summary:** The incident was triggered by the system reaching a high disk usage threshold. This caused search and analytics engine to temporarily stop processing data. **Resolution:** The threshold was adjusted, restoring normal service operations. **Preventive Measures:** We are implementing a disk capacity expansion to ensure the system remains fully operational and to prevent recurrence..

Read the full incident report →

Started Oct 20, 2025, 08:00 AM UTC· resolved Oct 27, 2025, 02:39 PM UTC

1. monitoring Oct 20, 2025, 08:00 AM UTC

   We are currently experiencing issues related to SMS delivery. This impacts: * **Guest users** accessing the captive portal using authentication methods that rely on SMS for OTP or login passwords. * **Administrators** accessing the admin interface who have enabled 2FA via cloud-based authentication. **Root Cause** This is due to a global issue on AWS, which affects our SMS provider. * [AWS Status](https://downdetector.co.uk/status/aws-amazon-web-services/) * [Twilio Status](https://status.twilio.com/) Multiple websites and applications are affected. We are monitoring the situation closely and will provide updates as they become available..

2. monitoring Oct 20, 2025, 12:00 PM UTC

   Based on our SMS Provider, partial recovery is seen and they are scaling systems to handle the influx of traffic. However they are still experiencing outages across multiple product lines due to an ongoing AWS incident. See [Twilio status](https://status.twilio.com/).

3. monitoring Oct 21, 2025, 06:32 AM UTC

   The issue on the AWS side appears to have been resolved. Our SMS provider may still be experiencing some latency in message delivery, but most services are now operating normally. You may notice occasional delays in SMS delivery throughout the day. We are continuing to monitor the situation closely and will provide an update later today if the latency persists..

4. resolved Oct 27, 2025, 02:39 PM UTC

   This incident has been resolved..

Read the full incident report →

Started Oct 16, 2025, 01:37 PM UTC· resolved Oct 16, 2025, 01:37 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Oct 16, 2025, 08:00 AM UTC· resolved Oct 16, 2025, 08:00 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →