Central 1 incident
INC221142 - RESOLVED: Client Centre Unavailable
Central 1 experienced a notice incident on May 4, 2026 affecting Central 1 Services and Payment Services and 1 more component, lasting —. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- resolved May 04, 2026, 04:36 PM UTC
Please be advised that Central 1 experienced a Client Centre (https://clients.central1.com/) outage today between 9:00 to 9:20 a.m. PT (12:00 to 12:20 p.m. ET). You may have experienced issues logging into Client Centre or Central 1 applications during that time. A postmortem will be provided within the next two weeks. Central 1 - [email protected] – 1.888.889.7878, press 1
- postmortem Jun 05, 2026, 10:54 PM UTC
**Postmortem**: **INC221339 – Client Centre and** [**Central1.com**](http://Central1.com) **Unavailable \(P2\)** On May 7, 2026, Central 1 experienced intermittent access issues impacting Client Centre and [Central1.com](http://Central1.com), following earlier instability first observed on May 4 \(INC221142\). Users across multiple financial institutions encountered inconsistent behavior including “Sorry” pages, timeouts, and HTTP 500 errors during login attempts. The incident was initially classified as P3 due to the presence of fallback access, but was escalated as impact persisted and authentication failures became more apparent. Post-incident review confirmed the event was caused by two overlapping issues that complicated detection and response. A third-party hosting provider performed a security remediation that introduced access restrictions, impacting Client Centre availability. At the same time, a separate issue within Central 1’s environment caused memory exhaustion on a single ADFS node, leading to repeated service restarts and HTTP 500 errors for a subset of authentication requests. The concurrency of these issues delayed root cause isolation and resulted in a fragmented and inconsistent user experience. **Point of failure:** Primary: Third-party hosting security remediation causing access instability Secondary: Memory exhaustion on ADFS node leading to service restarts and authentication errors. Contributing Factors were elevated authentication traffic \(user retries and redirect loops during outage conditions\) and no monitoring or alerting for ADFS memory/resource thresholds. The initial focus on vendor-related symptoms delayed identification of internal SSO degradation. **Corrective Actions** * Implemented monitoring and alerting for ADFS memory exhaustion \(Completed\) * Establish ADFS performance baselines to detect abnormal traffic patterns \(In progress\) * Evaluate and implement ADFS capacity improvements \(Under assessment\) * Formalized vendor escalation path for hosting-related incidents \(In progress\) This incident highlights the complexity introduced by concurrent failures across vendor-hosted and internal identity systems. Improved observability and clearer separation of symptom domains will be critical to accelerating diagnosis and ensuring more consistent user experience during future incidents. Jason Seale | Director of Client Support Services [[email protected]](mailto:[email protected]) | 778.558.5627