StrongDM Outage History

On February 17, 2026, some customers experienced elevated latency in the US Control Plane due to a relatively small number of specific query log requests. These specific requests were searching for a very small subset of queries within a very large dataset, which created significant server load for such a small number of requests. We implemented safeguards to improve log retrieval behavior and restored system performance. These safeguards should not affect normal query retrievals, but will reduce the load of specific query log requests by spreading out the request over a longer time period. Longer term, we are prioritizing other improvements to our query log architecture.

**Summary** On December 11th 2025, StrongDM experienced a service degradation affecting the US Control Plane. The issue was caused by resource exhaustion from an internal monitoring component and lasted approximately 73 minutes before service was fully restored. **What Happened** An internal monitoring component configured to collect operational telemetry was unable to process data efficiently under US production load. This led to resource exhaustion on the Control Plane. UK and EU Control Planes were not affected due to lower total throughput volumes. **Resolution** Infrastructure rolled back the monitoring component's configuration, immediately relieving resource pressure and restoring normal service. **Prevention & Remediation** To prevent recurrence, StrongDM is updating testing processes to better catch issues like this and revising configuration review processes for internal tooling updates.

**Summary:** During a routine system update on October 2, a server release was pushed to production that changed how tokens were validated, which led to failed connections to resources. Our internal canary deployment caught the issue and alerted the team. They started to rollback the change when we started to learn about customer impact. There were two compounding issues that caused this outage. **Cause:** It took some time for the issue to manifest in our Canary environment. By the time the system alerted, the build was deemed OK and pushed to production. Which was the ultimate root cause of the failure. **Impact:** * Disruption to resource connections. * Users who logged in during the window needed to re-authenticate. * No unauthorized access or security exposure. **Remediation & Prevention:** * Extending the delay between staging and production deployments for better early detection. * Updating infrastructure to manage environment

On December 3rd, SDM released a server build that added a new index to the table tracking latency between nodes. While the build succeeded on the EU and UK Control Planes, it failed on the US Control Plane. Retrying the build on the US Control Plane left the index in an invalid state, which went undetected by our migration tools. The following day, December 4th, SDM released a server build that relied on the new index. Without the index, node-to-node latency was no longer stored, and approximately three minutes later, the routing system stopped attempting multi-hop routes. This issue was limited to the US Control Plane, as the index was successfully created in the EU and UK Control Planes. StrongDM has already taken steps with internal processes to ensure that this kind of issue does not repeat in the future. Thank you for your patience and understanding.

A recent update revealed an underlying issue with our replica database. Internal alerts flagged the problem and the incident was declared when StrongDM received customer support tickets. To resolve the issue and prevent recurrence, our Infrastructure team made improvements to query monitoring and adjusted how we manage replica lag within RDS. **Incident Timeline:** * **Sep 5, 20:49 UTC** - Change deployed * **Sep 6, 13:50 UTC** - First problem report from internal alerts * **Sep 6, 15:15 UTC** - Tickets from two customers, incident declared, replica disabled * **Sep 6, 15:59 UTC** - Incident resolved

Summary: On August 1st at approximately 1 PM PST, production experienced a limited partial outage that affected at least 2 customers. Users who navigated to the AdminUI with an expired authentication due to session timeout were presented with an error page. Normally, those users would be redirected to a login page. This affected CLI and Desktop SSO logins as well. Impact: Users that had already had an authentication which had expired would see an error screen when going to the AdminUI. Valid authentications or logged out users did not see the issue. Clearing the browser removed the issue