Cornerstone incident
Issue with Core User Management functionality in US SL4 accounts
Cornerstone experienced a minor incident on August 10, 2026 affecting Response Time, lasting 23h 48m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating Aug 10, 2026, 03:14 PM UTC
Admins are currently unable to edit user records in the Production environment. When attempting to open a user record for editing through Admin > Tools > Core Functions > Users, the request fails and an error message is displayed ("An error occurred while processing your request"). The issue has been observed across multiple US SL4 (AWS) portals. Our Engineering Team is actively looking into this concern. We will keep you posted on any significant updates.
- monitoring Aug 10, 2026, 04:05 PM UTC
UPDATE: The issue seems to be impacting the Core User Management functionality (Example: unable to view or edit user records, View Universal profile, API services related to User record management) Our Engineering Team has confirmed the issue to be resolved. We will continue to closely monitor the situation to check its reliability.
- resolved Aug 11, 2026, 03:02 PM UTC
Following a period of monitoring, the implemented fix has remained stable, and this issue has been confirmed as resolved. Thank you for your patience and understanding!
- postmortem Aug 18, 2026, 03:21 PM UTC
**Incident Summary** Starting August 10th, 2026, users in the US RES PRD environment experienced intermittent issues with user management functionality and other portal functions dependent on core user services. **Impact** Affected users were intermittently unable to edit user records and may have experienced timeouts or errors when accessing other functionality dependent on core user services. The impact was limited to requests routed through the affected capacity, while healthy capacity continued to serve requests normally. **Root Cause Analysis \(RCA\)** The issue was related to instability affecting a subset of application capacity. Multiple services became unhealthy on the affected nodes, resulting in intermittent request failures and timeouts for functionality dependent on those services. The remaining healthy capacity continued to serve requests normally. **Resolution** The affected nodes were identified and recycled to restore service health. Following the recovery actions, the affected services returned to a healthy state and intermittent timeout issues were resolved. **Preventive Measures** * Monitoring and alerting for unhealthy application capacity will continue to be reviewed to ensure timely identification and remediation of similar conditions. * Post-recovery validation will be performed to confirm that affected capacity has returned to a healthy state before normal traffic handling is resumed.