Rise Up Outage History

Between 12:03 and 14:23 (CEST) on July 6, some users were unable to sign in via SSO on a subset of platforms. Sign-in attempts during this window would not complete and could return users to the login screen. Users with an already active session were not affected, and no data was impacted. The issue was introduced by a release deployed at 12:03 that affected how authentication tokens are handled at the end of the SSO sign-in flow. The cause was identified and a fix was deployed, fully restoring SSO sign-ins. No action is required - affected users can now sign in normally.

Between approximately 09:32 and 10:06 CEST, some users may have experienced loading errors or a blank page when accessing the platform. The issue stemmed from a configuration change affecting the delivery of certain static resources. Users with an active session were not impacted. The change was identified and rolled back, and service was fully restored at 10:06 CEST. We apologize for any inconvenience.

Earlier today we experienced elevated load that impacted platform performance. The issue has been resolved and additional safeguards have been put in place.

This incident has been resolved.

Between 10:10 and 10:26 CET our application experienced degraded performance and intermittent unavailability due to an unexpectedly long-running database operation. This led to an accumulation of backend connections and affected some users ability to access the application. We identified and mitigated the issue by adjusting configuration parameters and restarting affected services. The platform is now fully operational, and we continue to monitor to ensure stability. We're implementing additional safeguards to prevent similar behavior in the future.

The issue has been fully resolved. A deployment misconfiguration caused inconsistent asset delivery across certain custom subdomains via specific CDNs today between 10:39-15:50 (UTC+1). We've implemented a fix and are monitoring to ensure stable performance. Future deployments will include safeguards to prevent recurrence.

Incident timeframe: 2026-02-07 00:00 to 2026-02-09 08:19:10 (UTC+0) During the above window, some users may have experienced intermittent errors or failures when accessing certain learning content stored in our backend storage. Impact varied depending on the type of content and how it was accessed. The incident was caused by an internal configuration issue affecting our storage integration layer. This led to certain requests for stored content failing under specific conditions. The configuration has been corrected and normal access to all affected content was fully restored at 2026-02-09 08:19:10 (UTC+0). We are adding automated checks and monitoring around our storage integration configuration and expiration parameters to detect similar issues earlier and prevent reoccurrence.

Between 12:05 and 13:38 CET, a deployment issue initially caused slowness on the platform. After resolution, we identified that steps and preview steps were unavailable during this timeframe. The incorrect configuration introduced during deployment was corrected. Furthermore, between 14:24 and 14:50 CET, an unexpected CPU spike usage affected platform performance. We manually scaled ressources to resolve it quickly and will work on better resource scaling anticipation. All services are now fully operational.

We’ve identified the issue as related to a recent code update affecting navigation during course editing. A fix has been deployed, and this incident is now fully resolved.

This incident was due to a misconfiguration of the way we forwarded values to our data lab. It’s now fully fixed.

At 9:00 AM (Paris time), we were informed that several pages were not loading correctly. After investigation, our technical team identified an issue affecting specific pages and deployed a fix. The service has been fully restored since 10:00 AM (Paris time). We are continuing to monitor the situation as a precaution.

This incident has been resolved.

This incident has been resolved.

This incident has been resolved. There was an issue with the way we handle auto-scaling where it didn’t scale quickly enough. We modified the auto-scaling configuration to ensure that it doesn’t happen again.