Technolutions Status Page

May 14, 2026

We initiated a failover at 12:30pm Eastern Time, the failover went smoothly, and databases are operating within expected performance ranges. We will initiate a failback later this evening following a restart of the primary service infrastructure. We will continue to monitor to ensure that performance levels remain within expected ranges.

May 4, 2026 · resolved May 4

The interruption in availability was caused by a loss of quorum in the failover cluster. We are continuing to investigate periodic network interruptions that have occurred following recent upgrades to the database infrastructure and operating systems. In the meantime, we have further hardened the cluster configuration to prevent unintended failovers and interruptions.

Apr 27, 2026 · resolved Apr 27

There have been no further issues. We will continue to operate with manual failovers for a bit longer as we validate the efficacy of the automatic failovers. We will also continue to monitor for any other conditions that may result from the database server upgrades.

Apr 26, 2026 · resolved Apr 26

There have been no continued impacts. The incident, which primarily affected databases on the LIMA cluster, was caused by an automated failover to secondary infrastructure. A routine servicing update to the third-party database engine introduced a behavioral change that, under specific conditions, resulted in an exhaustion of worker threads. Upon failing over, some databases were slower to recover as a result of a related exhaustion of worker threads on this secondary node. We have disabled the functionality that resulted in this behavioral change, as advised by the vendor, and have increased the ceiling for worker threads to reduce the potential for reoccurrence. Everything remains stable at this time, and we will continue to monitor for any further issues.

Dec 5, 2025 · resolved Dec 11

We have completed our review of the incident that affected the processing of certain exports and imports on 12/5. Slate uses a cluster of worker nodes to process background jobs. These nodes are periodically refreshed with the latest version of Slate, and on 12/5 they were updated to a build that included a newer version of a third-party AWS SDK. Worker nodes employ a shadow-copying mechanism that creates local cached copies of binary dependencies to avoid locking files on shared storage. This mechanism refreshes cached assemblies only when it detects a change in the assembly’s identity, which typically occurs during breaking or versioned updates. The updated AWS SDK introduced an internal structural change: a property was moved from a derived class to its base class. Although no public API signature changed, the compiled IL binding did. Because the assembly’s identity did not change, the shadow-copy cache was not refreshed. As a result, the worker nodes attempted to execute IL referencing the property on the derived class against the older cached version, causing a runtime “method not found” error. On the afternoon of 12/5, we reverted the worker nodes to the earlier AWS SDK version, restoring normal operation. We have since implemented enhancements to our worker-node architecture to provide stronger cache isolation and to ensure that updates to the AWS SDK and other dependencies are correctly recognized, even when internal changes occur without a corresponding change in assembly identity. Web nodes use a different shadow-copying mechanism and were not affected.