Worklytics Outage History
Worklytics is up right nowPingoru has recorded 3 incidents for Worklytics: 0 in the last 12 months and 0 in the last 90 days.
Show as a table
| Month | Incidents | Hours with an open incident |
|---|---|---|
| April 2026 | 0 | 0 of 720 (0%) |
| May 2026 | 0 | 0 of 744 (0%) |
| June 2026 | 0 | 0 of 720 (0%) |
| July 2026 | 0 | 0 of 744 (0%) |
| August 2026 | 0 | 0 of 744 (0%) |
| September 2026 | 0 | 0 of 720 (0%) |
| October 2026 | 0 | 0 of 744 (0%) |
| November 2026 | 0 | 0 of 121 (0%) |
Incidents, newest first
Minor October 20, 2025 [Data Lag] anticipated data lags due to AWS outages 12h 10m Worklytics Platform, data-processing-platform
Started Oct 20, 2025, 06:00 AM UTC· resolved Oct 20, 2025, 06:10 PM UTC
- resolved Oct 20, 2025, 06:00 AM UTC
**Additional context** Beginning around 06:00Z on Oct 20, 2025, AWS has experienced repeated downtimes; while Worklytics is not directly effected, as our core platform runs primarily in GCP, many customers host our data sanitization proxy in AWS. Due to the AWS downtimes, we are seeing data requests from our platform slowed/failing for these customers. If this includes you, you should expect data delivery to be late this week corresponding/proportional to the downtime.
Major October 8, 2025 [Downtime] slow login, MSFT SSO down 1m Worklytics Platform
Started Oct 08, 2025, 10:38 PM UTC· resolved Oct 08, 2025, 10:39 PM UTC
- resolved Oct 08, 2025, 10:38 PM UTC
start: 2025-10-08T21:44:00.000Z **Additional context** Since ~14:44 PT, we've seen our Microsoft SSO failing to load, and high latency on our login page generally (due to this loading poorly).
Major October 8, 2025 🛑 login is slow, MSFT SSO in particular is affected 17h 31m Worklytics Platform, worklytics-web-portal
Started Oct 08, 2025, 09:53 PM UTC· resolved Oct 09, 2025, 03:24 PM UTC
- resolved Oct 08, 2025, 09:53 PM UTC
The Worklytics Web Portal was degraded from approximately 14:44 PT until 17:20 PT. The Root Cause was increased latency in GCP Secrets Manager, resulting in configuration information stored there being slow to load or timing out entirely. This was an unexpected and unhandled condition. The code to access the secrets manager included handling of outright failures (proactively disabling the SSO methods depending on the inaccesssible secrets) - but not extreme slowness. The default Secrets Manager client timeout is 60s (specified by Google, not Worklytics); we should have lowered this based on our use case ( a web app configuration). Given that we were lazy-loading configuration information for SSO providers, and that 60s is typically HTTP timeout of web browsers, login requests were simply timing out. What *should* have happened some SSO methods simply disappearing from the application. Two fixes have been made: - lowering timeouts as described above to well within HTTP timeout - moving some non-Secret configuration information out of Secrets Manager, to limit dependency on the service; certain values were kept their for convenience of having all config in one place, rather than bc they were values that actually needed to be handled as secrets. Limiting use of secrets manager to truly secret values should reduce the dependency and risk.