Sympa HR experienced a minor incident on August 31, 2026 affecting System availability, lasting 2h 27m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating Aug 31, 2026, 07:09 AM UTC
Dear Customers, We are currently investigating degraded performance affecting the login service. Customers can still log in, but the login process may take significantly longer than usual. Our team is actively investigating the cause and working to restore normal login performance. We apologize for the disruption and appreciate your patience. Your Sympa Team
- monitoring Aug 31, 2026, 07:29 AM UTC
Dear Customers, We have taken corrective action to address the degraded performance affecting the login service. According to our monitoring, the login service started operating normally at 10:25 EEST. Our team is continuing to monitor the service closely to confirm that performance remains stable. We apologize for the disruption and appreciate your patience. Your Sympa Team
- resolved Aug 31, 2026, 09:36 AM UTC
Dear Customers, The login service has continued to operate normally, and our monitoring confirms that performance remains stable. We are therefore closing this incident. We apologize for the disruption and appreciate your patience. Your Sympa Team
- postmortem Sep 01, 2026, 09:07 AM UTC
**What happened** Between the evening of 30 August and mid-morning on 31 August, some customers experienced slower than normal login times. Logins completed, but response times were degraded during this period. **Why it happened** An internal configuration item was not renewed on schedule, which caused a background processing job to fall behind. Clearing the resulting backlog created a short load spike that extended the degraded performance before service returned to normal. **What we have done** Restored normal processing and cleared the backlog. Automated the renewal of this class of configuration so it no longer depends on a manual step. Added earlier alerting so the condition is detected before it reaches customers. Added pacing to backlog processing so recovery cannot itself degrade performance. **Timeline \(EEST\)** 30 Aug, evening: first signs of degraded background processing 31 Aug, 09:03: corrective change applied 31 Aug, 09:40: background processing resumes 31 Aug, 10:30: login performance back to normal