Secret Server Cloud: Access Issues and Errors When Navigating Between Pages

Update timeline

1. investigating Jul 28, 2026, 02:03 PM UTC

   We are investigating reports that some Secret Server Cloud users are unable to sign in and are being redirected to an error page. We are actively working to resolve the issue and will provide another update soon.

2. identified Jul 28, 2026, 02:15 PM UTC

   We have identified the root cause of the issue. A configuration change prevented affected tenants from connecting to the database, causing the application to fail to load and display error pages. Our engineering team has applied a corrective change and is validating the fix. We will provide another update soon.

3. monitoring Jul 28, 2026, 04:34 PM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Jul 28, 2026, 11:07 PM UTC

   This issue has been resolved, and services are operating normally. We will continue to monitor to ensure stability.

5. postmortem Sep 15, 2026, 06:39 AM UTC

   ## Incident Overview On July 28, 2026, a small subset of Secret Server Cloud tenants were unable to sign in or encountered errors when navigating between pages. Affected tenants could not establish a connection to their database, which caused the application to fail to load. * Start: July 28, 2026, approximately 03:11 AM UTC * End: July 28, 2026, approximately 04:05 PM UTC * Regions impacted: Very small subset of tenants across multiple regions ## Root Cause and Remediation During an internal release step, a supporting service was rebuilt and deployed at a version that did not match the version running in Secret Server Cloud production. The two versions format database connection settings differently, and the newer format included a setting the production application did not recognize. That value was written to an internal cache and served to tenants as their cached entries were refreshed. Because refresh timing varies by tenant, tenants became affected at different points rather than all at once, which is why impact was limited to a subset rather than the full region. Our Engineering team identified the root cause, redeployed the supporting service at the version matching production, and cleared the affected cache entries. Access was restored as corrected values propagated, and each affected tenant was validated individually before the incident was closed. ## Preventative Actions * Add automated compatibility testing and deployment validation checks to catch configuration and version mismatches before code reaches production. * Improve detection of tenant-level database connection failures so this class of issue is identified through internal monitoring rather than customer reports. * Strengthen internal review processes for cache and configuration management to reduce the risk and impact of similar issues in the future. We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.