Is CyberQP down?

What happened: Starting around 20:50 UTC on October 16, 2026, some users in the US region couldn't sign in to Quickpass QTech chrome extension. They saw a "403 Forbidden" error, and some briefly saw a "Server Error, try again in 30 seconds" message. Over the next few days it affected a growing number of login attempts. Root cause: Our web application firewall uses a set of rules managed by our cloud provider. Those rules were updated on the provider's side, and one of them started wrongly flagging a normal part of our sign-in process as a threat. The firewall then blocked those login requests. We made no changes to our systems before the issue started. Security impact: There was no security breach, and no data was exposed or compromised. The firewall blocked legitimate traffic. Nothing got past it that shouldn't have. Our authentication systems were healthy throughout, and no customer or partner data was accessed. The only impact was that users couldn't log in. Resolution: We adjusted the firewall configuration so the sign-in process works again. All other protections stay fully in place. Logins were restored at 1:42 PM UTC, 19th Oct 2026.

What happened: Starting around 20:50 UTC on October 16, 2026, some users in the US region couldn't sign in to Quickpass QTech chrome extension. They saw a "403 Forbidden" error, and some briefly saw a "Server Error, try again in 30 seconds" message. Over the next few days it affected a growing number of login attempts. Root cause: Our web application firewall uses a set of rules managed by our cloud provider. Those rules were updated on the provider's side, and one of them started wrongly flagging a normal part of our sign-in process as a threat. The firewall then blocked those login requests. We made no changes to our systems before the issue started. Security impact: There was no security breach, and no data was exposed or compromised. The firewall blocked legitimate traffic. Nothing got past it that shouldn't have. Our authentication systems were healthy throughout, and no customer or partner data was accessed. The only impact was that users couldn't log in. Resolution: We adjusted the firewall configuration so the sign-in process works again. All other protections stay fully in place. Logins were restored at 1:42 PM UTC, 19th Oct 2026.

We're experiencing an high priority issue with the Agent connectivity, and are currently looking into the root cause. Apologias for the inconvenience. All updates will be posted here.

The issue has been identified and addressed

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

This incident has been resolved.

## Service Incident Report — EU Region **Date:** 3 September 2026 **Duration:** 11:49 – 13:23 UTC \(1 hour 34 minutes\) **Region affected:** EU **Status:** Resolved ### Summary On 3 September 2026, our agent connectivity service in the EU region became unavailable for approximately 1 hour 34 minutes. During this window, agents in the EU region were unable to establish connections, and scheduled background job processing was delayed. Service was fully restored by 13:23 UTC and has been stable since. Regions other than EU were unaffected. ### Impact For the duration of the incident, in the EU region only: * **Agents could not connect** to the platform. Existing sessions were interrupted and new connections failed. * **Scheduled and queued background jobs were delayed.** Queued work resumed processing after recovery. ### What happened Two factors combined: A memory management issue in our agent connectivity service caused it to gradually consume increasing memory over an extended runtime, eventually making it slow to respond to automated health checks. Separately, the health check timing configuration in our EU region allowed a narrower recovery window than in other regions. As a result, instances that would otherwise have recovered were restarted automatically before they could return to service, and those restarts escalated into a repeated restart cycle rather than self-healing. An automated recovery process then replaced the affected instances, but the replacements encountered the same timing constraint on startup, which extended the outage rather than ending it. ### Resolution Our engineering team identified the cause and applied a configuration correction directly to the EU environment at 13:23 UTC, aligning its health check timing and resource allocation with values already proven in our other regions. Both affected services returned to a healthy state immediately and ran for over 100 minutes with zero restarts before the incident was closed. ### Preventive actions 1. **Health check timing corrected in the EU region** — completed 3 September 2026. 2. **Proactive review and alignment of the same configuration across all remaining regions**, so no region carries a narrower recovery margin than another. 3. **New automated alerting on repeated service restarts**, so this class of degradation is detected and escalated before it affects availability. 4. **A safeguard added to our automated recovery process** to prevent it from restarting all instances of a service simultaneously. 5. **Continued engineering work to eliminate the underlying memory management issue** in the agent connectivity service, rather than relying on tolerance settings alone. ### Questions For questions about this incident or its impact on your tenants, contact [[email protected]](mailto:[email protected]).