Squiz Status Page

Apr 15, 2026 · resolved Apr 26

Squiz teams have worked with our 3rd party service provider, and all data impacted by the integration delay has been restored. This incident has been resolved, and all systems impacted are working as expected.

Mar 12, 2026 · resolved Mar 13

The incident has been resolved and Advanced Forms access should be restored for all customers.

Mar 4, 2026 · resolved Mar 4

Squiz teams have worked with our 3rd party service provider, and a fix has been deployed for the current Incident. This restored service for all affected customers. We apologise for this degradation of service and thank you for your patience while we worked on the resolution. A postmortem will be provided via https://status.squiz.cloud once we have worked with our service provider.

Feb 20, 2026 · resolved Feb 21

**Executive Summary** On Friday, February 20, 2026, at 1748 UTC, a global Cloudflare incident impacted network routing used to deliver traffic to services hosted on the Squiz DXP platform. During this time: * All DXP users, and Squiz cloud customers using Cloudflare, were unable to log in to any administrative interfaces in the Squiz DXP, including the Console, Content Management System \(Matrix\), and Funnelback. * Customer frontend websites using Cloudflare were returning cloudflare errors “Connection timed Out” This issue was caused by a change that Cloudflare made to how our network manages IP addresses. Cloudflare have provided a detailed analysis of the incident at [https://blog.cloudflare.com/cloudflare-outage-february-20-2026/](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/) Restoration of the cloudflare service for individual customers ranged from between 30 mins to 3.5 hours depending on the IP configurations for each customer. If you require more information specific to your solution please log a ticket via the My.Squiz portal requesting a Custom Post Incident Report. Squiz would like to remind customers to subscribe to the Squiz Status page at [status.squiz.net](http://status.squiz.net) to receive real time notification of Major Incidents. **References** * Cloudflare incident Page: [https://www.cloudflarestatus.com/incidents/kwy3dt82bwbt](https://www.cloudflarestatus.com/incidents/kwy3dt82bwbt) * Cloudflare incident Blog:  [https://blog.cloudflare.com/cloudflare-outage-february-20-2026/](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/) * Squiz Status Page: [https://status.squiz.cloud/](https://status.squiz.cloud/) **Timeline:  20 Feb \(UTC\)** * Incident start time: 1749 UTC * Squiz Incident declaration: 1800 UTC * Initial Squiz Status Page notifications posted: 1809 UTC * Cloudflare reported full resolution for anycast customers: 2053 UTC * Cloudflare reported full resolution for spectrum customers: 2259 UTC * Cloudflare marked the incident resolved on at 23:50 UTC * Squiz Declared Incident resolved: 0000 21 Feb UTC

Jan 23, 2026 · resolved Jan 24

## Incident Summary A problem on a 3rd party Network impacted the Internet connectivity between two different service providers that Squiz utilise for Internet transit and CDN for some customers hosted within our Australian Data Centres. Squiz DXP services were unaffected The service degradation began on **Jan 23, 11:56 AEDT**, and ended **Jan 24, 10:22 AEDT** when the 3rd party Network operator fixed their network. Squiz continued to monitor for any further impact for an extended length of time, and the incident was officially resolved **Jan 24, 23:26 AEDT,** once we received confirmation from our service provider as to the root cause. ‌ ## Incident Timeline This is a high-level summary of the key events during the incident. All times are in AEDT. | **Time** | **Event** | | --- | --- | | Jan 23, 2026 | | | 11:56 | Service Degradation begins. | | 12:33 | First report of customer impact. | | 12:34 onwards | Further reports of impacted services, and initial investigation to identify the cause. | | 14:17 | A formal incident was declared and a response team assembled to investigate. | | 15:49 | Following multiple attempted mitigation efforts by Squiz Technical Staff, and further analysis, the problem was escalated to Squiz’s Internet Transit and CDN service providers. | | 19:24 | Squiz’s Service providers identify an issue with connectivity between each other, via a 3rd party network. | | Jan 24, 2026 | | | 09:02 | Signs of substantial service improvement. | | 10:22 | Service degradation ends and monitoring begins. | | 19:40 | Confirmation received from our transit service provider that the 3rd party network operator implemented a fix at the time we saw services return to normal. | | 23:26 | Incident Resolved | ## Customer Impact A subset of Squiz customers with sites hosted within those Data Centres, \(those whose service was dependent on both these service providers\) experienced mild to severe service degradation throughout this incident - typically manifesting as pages failing to load, excessive load times, and an inability to access administration interfaces. As a result, this incident was classified as a Priority 1. DXP services were unaffected. ## Root Cause Analysis The incident was caused by a problem on a 3rd party Network between two different service providers that Squiz utilise for Internet transit and CDN for some customers hosted within our Australian Data Centres.The issue occurred outside our platform and network boundary, and that of all our immediate partners and service providers. ## Mitigation and Corrective Actions No technical corrective actions were noted for Squiz, as the incident was due to a problem with a third-party network with whom Squiz does not have a relationship.