Major incident

TimeEdit: Service unavailable

Affected: Curriculum, Curriculum, Curriculum, Curriculum, Workload, Workload, Workload, Workload, Scheduling, Scheduling, Scheduling, Scheduling, REST API, SOAP API, System Services, Reserve, Reporting, Data Manager, REST API, REST API, Rest API, SOAP API, SOAP API, SOAP API, System Services, System Services, System Services, Allocate

Current status of TimeEdit: Operational — live TimeEdit status

Timeline

1. Sep 5, 2026, 11:54 UTC
   investigating
   TimeEdit is currently offline while our team completes work on the platform. Next update by 14:30 CEST.
2. Sep 5, 2026, 12:34 UTC
   investigating
   We are continuing to investigate this issue.
3. Sep 5, 2026, 13:37 UTC
   identified
   The issue has been identified and a fix is being implemented.
4. Sep 5, 2026, 15:21 UTC
   identified
   We are continuing to work on a fix for this issue.
5. Sep 5, 2026, 16:03 UTC
   identified
   We are now in the final stage of redeploying our services and expect them to be back up by 21:00 CEST.
6. Sep 5, 2026, 18:10 UTC
   resolved
   This incident has been resolved. A post-mortem will be published on Monday 7 September.
7. Sep 8, 2026, 09:36 UTC
   postmortem
   **Summary** On September 5, 2026, we identified an issue involving an internal deployment credential. Because we could not immediately determine the scope or potential impact, we made the precautionary decision to take production environments offline while we secured the affected environment and verified that services could be safely restored. Scheduling \(Core and Viewer\), Curriculum and Workload were restored that evening. All remaining production services were restored during September 6. Test environments were restored on September 7. **Impact** Production services were unavailable during portions of September 5 and September 6. The duration varied by region and service as environments were restored in sequence. Engagement was not affected. We have been able to confirm that no data was accessed. **Cause and precautionary shutdown** The issue involved unauthorized access to an internal deployment credential. Given the credential’s permissions and the uncertainty about the potential impact, we took production environments offline as a precaution while we investigated and completed remediation. **Resolution** The credential was revoked and all credentials in the affected environment were rotated. Services were then redeployed, verified and restored region by region. Creation of this type of long-lived credential has been blocked across our organization.

Updates as published by TimeEdit (original).