Datto Outage History

**Summary:** Between 2026-03-25 13:30 UTC and 2026-03-25 14:10 UTC, about 66% of Connect Booster partners were unable to login to their instance\(s\) or process payments. **Root Cause:** ConnectBooster attempted to auto-scale and provision new instances of the application to accommodate more load, however these new instances failed to start due to a dependency failure. **Incident Timeline:** * Identified: 2026-03-25T13:46 UTC * Resolved: 2026-03-25T14:10 UTC **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps: * Improving our independent monitoring systems to ensure these failures are caught and remediated more quickly. * Modifying startup dependency requirements to be less stringent. In the future, in the event of a failure in certain parts of the product or in the event of certain external vendor failures, unaffected parts of the product will continue to function.

**Summary:** Between approximately 23:00 UTC on 18 March 2026 and 12:07 UTC on 20 March 2026, partners on the Merlot \(EU2\) platform experienced an issue whereby alerts raised by devices were not processed by the service and did not appear in the Web Application within their accounts. **Root Cause:** The root cause was identified as a defect in the alert-processing mechanism, which prevented the service from processing alerts containing certain special characters. When alert processing fails, a retry mechanism is triggered to attempt reprocessing a set number of times. However, an additional defect caused the retry mechanism to enter an infinite loop, never discarding the affected message. The combined effect of these issues caused alert processing to stall on the affected alerts, resulting in a continuously growing message queue. Initial standard remediation measures were unsuccessful; therefore, the R&D and Operations teams force-cleared the queue and restarted the processing service to recover from the incident. Following remediation, the service returned to a healthy state, and both historical and new alerts began processing in near real time for devices where alert conditions were still met. The R&D team is addressing the identified defects at the earliest opportunity. In the interim, configuration changes have been applied to minimize the risk of the issue reoccurring. **Incident Timeline:** Identified: 2026-03-20 09:12 UTC Public Notification: 2026-03-20 10:48 UTC Resolved: 2026-03-20 12:07 UTC **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, the following actions are being taken: * The Operations team has implemented direct monitoring of the alert-processing queue to notify responders if an abnormal state develops that could impact service performance. * The Operations team is also working on improving monitoring of alert-processing failures to ensure unexpected states are reviewed and addressed in a timely manner. * R&D and Operations playbooks, along with escalation procedures for standard remediation measures, have been updated based on lessons learned during the response to this incident.

**Summary** Around **2026-03-06 9:40 AM EST,** partners on the Zinfandel platform started experiencing delays in both Quick and Scheduled Job execution. The issue was initially mitigated by 12:00 PM EST; however, the steps taken to restore service inadvertently caused the problem to reoccur later that afternoon at approximately 2:13 PM EST. The R&D and Operations teams fully resolved the issue by 2:47 PM EST. **Root Cause and Resolution** The initial incident was triggered by an unusually large-scale alert resolution operation, which created a significant backlog of processing tasks within the database. The high volume of queued work caused processing times to exceed the allowable execution window. This resulted in repeated retries, which continually saturated the database and prevented other operations from running normally. To alleviate the load, the task scheduling service was scaled down, and the queuing services were recycled, which reduced database pressure and restored normal operation by approximately 12:00 PM EST. However, at around 2:13 PM EST, these earlier mitigation steps produced an unintended side effect: they constrained the throughput of the service responsible for processing device audits. This limitation caused additional downstream delays in Job execution across the platform. The service was subsequently scaled back up to full capacity, and all services were confirmed healthy by **2:47 PM EST**. **Preventative Measures** To reduce the likelihood and impact of similar incidents in the future, the following steps are being taken: * **Resolution of Related Product Issues:**` `The R&D team has identified a backend software defect that contributed to the incident. A fix is scheduled for the **14.9 release**. * **Enhanced Monitoring, Alerting, and Response:**` `The Kaseya R&D team is reviewing additional monitoring capabilities to provide deeper insight into application performance at the component level for key services. * **Improved Incident Management and Response:**` `Global Kaseya teams will continue to receive training and coaching on Incident Management playbooks to ensure that all internal stakeholders are promptly informed and take coordinated action when events occur.