We had a day of unplanned downtime starting the morning eastern time on 7/27/2025. I truly apologize for the downtime and for the work of processing in orders and support tickets that cropped up on your side during our downtime.
The quick bullets are:
This was not an attack, but a series of systems failures (electrical systems in the datacenter, followed by the HVAC systems, followed by the fail-over systems).
All data is available as it was the moment before the downtime happened. That means you can login to your LimeLM account and it's all there as it was.
All data was available encrypted-offsite during the downtime (so there was never a chance of losing your data).
While we didn't cause the failure, we're responsible for ensuring a failure like this doesn't happen for this length of time in the future (including more robust failover mechanisms).
Let me expand on the bullet points above. We had a day of unplanned downtime starting yesterday morning (Eastern U.S. time, "Boston time") going into this morning. During this downtime our services were unavailable. Unfortunately (and atypically for us) this also meant our mail servers were also down.
For LimeLM customers this downtime meant the following:
All web API calls (including things like generating product keys, changing custom license fields, etc.) would have timed-out (i.e. get an error and not be processed by us).
Any new customers with product keys that they haven't yet activated would not have been able to activate (they would have gotten an "Internet error", for example in C/C++
TA_E_INET)Any customers attempting to move their product keys between machines (deactivate on an old machine and activate on a new machine) would not have been able to carry out this action.
To sum up: new customers and customers actively changing which machines their licenses were on would not have been able to activate / make that change during the downtime.
The good news is that existing customers that were already activated would not have been affected. Our design of TurboActivate, TurboFloat, and TurboFloat Server is such that it doesn't require constant connections with our activations servers (no one would want that!). So, if you're using our TurboActivate API as designed, existing customers that weren't actively moving their licenses were unaffected.
Data integrity and security
During this entire downtime we had up-to-date encrypted copies of the data offsite. Meaning the data was always available to us outside of this datacenter. So we had a "cold copy" of the data in our possession. We also had a warm backup (a server at another datacenter) with an identical copy of the data. The problem was our failover mechanisms were in the same datacenter that the "primary copy" was residing in.
So, while we had some of the infrastructure in place to handle the data-failover, some of our critical servers were in the failed datacenter. Which is unfortunate, and is a problem we're actively addressing going forward. This is the first time that this type of issue has bitten us.
Long story short: your data was never in danger. We work extremely hard to make sure that backups are accurate, up-to-date, and encrypted.
This downtime issue has been addressed, but we're investigating alternative failover methods to ensure downtime isn't this long again. This includes migrating to a more modern and well-equipped datacenter. We'll be researching and deploying these changes in the background during the coming months. These changes will happen without downtime.
This will be a significant capital and time expense but it will ensure this multi-hour downtime will be extremely unlikely to happen in the future.
Again, I'm truly sorry for the downtime.
— Wyatt O'Day
Founder & CEO of wyDay