Kaseya Incident History

1. monitoringSep 10 · 18:33 UTC

   Our R&D team continues to make progress restoring and stabilizing Microsoft 365 backup operations. Additional Microsoft Graph API migrations have been completed across multiple regions, and recovery efforts continue to deliver improvements across affected services. To support recovery and maintain backup reliability, backup cadence remains temporarily adjusted for some Microsoft 365 workloads. In addition, changes have been implemented to distribute backup processing more evenly across regions, helping reduce peak load and improve overall system performance. As a result of these optimization efforts, some customers may continue to experience delayed backup start times or intermittent backup delays while processing is normalized across the environment. Backup operations remain active across all supported Microsoft 365 services. Many affected services and regions have stabilized, and recovery progress continues across the remaining environment. Our teams remain focused on completing the remaining work and are closely monitoring backup health and performance.

Reported by Kaseya on their status page.

1. monitoringSep 10 · 09:38 UTC

   The Kaseya R&D Team responded to alerts related to the eu.rocketcyber.com site. The incident lasted for about 30 minutes during which Rocketcyber customers hosted in the EU region were not able to access the product. The issue is now resolved, and we are currently monitoring the health of the service.

Reported by Kaseya on their status page.

1. monitoringSep 9 · 23:23 UTC

   We are continuing to monitor for any further issues.

Reported by Kaseya on their status page.

1. identifiedSep 9 · 12:54 UTC

   The issue has been identified and a fix is being implemented.

Reported by Kaseya on their status page.

1. resolvedSep 9 · 12:54 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. postmortemSep 8 · 21:21 UTC

   **Datto EDR - Mass Detection on Windows Behavior – 2026-08-27**  **Summary**  Between **2026-08-27 08:00 UTC** and **2026-08-27 16:00 UTC**, Datto EDR customers experienced an elevated volume of detections generated by the **Possible Shim Database Persistence via sdbinst.exe** detection rule. The increase in alerts created additional operational overhead for customers and analysts reviewing alerts. No service outage occurred, and endpoint protection functionality remained operational throughout the event. The issue was resolved after the detection rule was updated to account for a newly observed legitimate Windows operating system behavior.   **Root Cause**  A legitimate Microsoft Windows behavior involving **sdbinst.exe** and the file path **C:\\Windows\\appcompat\\cloudsdb\\apppatch.sdb** was not covered by the existing exclusions within a Datto EDR detection rule. A change in Microsoft's behavior matched the criteria of the rule **Possible Shim Database Persistence via sdbinst.exe**, resulting in a higher-than-expected volume of detections. The rule logic was updated to properly account for the newly observed behavior and eliminate the unintended detections.   **Incident Timeline**  * **Identified:** 2026-08-27 08:00 UTC \(customer reports and alert volume increase identified\)   * **Public Notification:** 2026-08-27 11:00 UTC \(incident escalated to Product and Detection Engineering teams and communications initiated\)   * **Resolved:** 2026-08-27 16:00 UTC \(updated rule deployed and alert volume returned to expected levels\)   **Preventative Measures**  To reduce the likelihood and impact of similar incidents in the future, we are implementing the following improvements:  **Enhancements to Monitoring and Alerting**  * Implement monitoring and baselining for individual detection rules to identify abnormal spikes in alert volume more rapidly.  * Develop internal metrics that provide visibility into detection trends and anomalous rule behavior before large-scale customer impact occurs.   **Enhancements to Incident Management and Response**  * Improve escalation workflows for significant detection-volume increases to ensure appropriate engineering resources are engaged as quickly as possible.  * Continue refining response procedures for detection-rule tuning and validation when unexpected platform or operating system behavior changes are observed.   **Detection Content Improvements**  * Enhance detection engineering review processes to account for evolving operating system behaviors and newly introduced legitimate execution patterns.  * Expand validation and exclusion testing for detection rules where operating system updates may introduce behavior changes that resemble suspicious activity.     **Customer Impact**  * Product Affected: **Datto EDR**  * Impact Type: **Increased detection volume / mass alerts**  * Service Availability: **No outage**  * Security Protection Status: **Protection remained active and operational**  * Customer Impact: Customers experienced increased alert volume requiring additional review and operational effort.   This incident has been fully resolved, and Datto EDR continues to operate normally.

Reported by Kaseya on their status page.

1. resolvedSep 8 · 16:26 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedSep 4 · 19:40 UTC

   Microsoft has fixed the issue with receiving email from external domains. We have verified that emails are now getting processed without issue. This incident is resolved.

Reported by Kaseya on their status page.

1. monitoringSep 4 · 16:47 UTC

   Following additional changes deployed by our R&D team, we are seeing continued improvement in Exchange backup success rates for customers hosted on pod 'aue1-saas-p0'. Our team is closely monitoring the environment as backup processing and success rates continue to recover.

Reported by Kaseya on their status page.

1. resolvedSep 4 · 14:06 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedSep 3 · 16:44 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. postmortemSep 3 · 14:24 UTC

   # Summary: Between 2026-08-06 05:41 UTC and 2026-08-06 18:03 UTC, ConnectBooster customers were unable to login to ConnectBooster using KaseyaOne Single-Sign-On \(SSO\). # Root Cause: An unexpected failure in a dependency used by the SSO login process caused login attempts to fail. ## Incident Timeline: • Identified: 2026-08-06 13:30 UTC • Public Notification: 2026-08-06 14:15 UTC • Resolved: 2026-08-06 18:03 UTC # Preventative Measures: To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. ## Enhancements to Monitoring and Alerting: * Enhance login workflow logging to provide improved visibility into authentication performance and failures across all login methods. * Implement monitoring and alerting for login workflows using request, error, and performance metrics, enabling the team to quickly identify and respond to authentication issues. ## Enhancements to Infrastructure Resiliency: * Streamline services within the SSO login workflow so that authentication can continue successfully even if related supporting services are unavailable.

Reported by Kaseya on their status page.

1. resolvedSep 2 · 23:17 UTC

   The issue preventing Secure Edge administrators from viewing recent usage information within Datto Network Manager has been resolved. Queued data has finished processing, and usage metrics are now available as expected. We appreciate your patience while we worked through this issue. Subscribe to the Kaseya Status Page for up to date information at https://status.kaseya.com/

Reported by Kaseya on their status page.

1. resolvedSep 2 · 16:51 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. postmortemSep 2 · 13:53 UTC

   **Endpoint Backup v2 - Assets in UniView may inaccurately report backup failures despite successful backup completion – 2026-07-27**    **Summary:** Between **2026-07-27 20:00 UTC and 2026-07-28 23:30 UTC**, Endpoint Backup v2 customers experienced an issue in which assets within UniView incorrectly reported backup failures, despite backups completing successfully.     **Root Cause:**   The incident was caused by a processing capacity constraint that delayed the synchronization of backup status information. As a result, recently completed backups were not reflected in the user interface in a timely manner, creating visibility issues for customers. Backup operations continued to complete successfully, and no backup data was impacted.    **Incident Timeline:**   * Identified: **2026-07-27 20:00 UTC**   * Public Notification: **2026-07-28 13:52 UTC**   * Resolved: **2026-07-28 23:30 UTC**      **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps.    * Implemented a more efficient data synchronization mechanism to reduce processing overhead, improve system performance, and accelerate the delivery of updated information across the platform.

Reported by Kaseya on their status page.

1. resolvedSep 2 · 10:11 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedSep 1 · 15:56 UTC

   The issue affecting access to the Datto RMM Vidal platform has been resolved.

Reported by Kaseya on their status page.

1. resolvedSep 1 · 13:27 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 31 · 20:11 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 31 · 17:34 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 31 · 13:43 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 31 · 13:40 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 28 · 18:43 UTC

   The issue affecting Activity Log performance on the Vidal Platform following the 15.1 release has been resolved. The Kaseya Engineering Team implemented a fix and has confirmed that Activity Logs are loading as expected after monitoring the platform to ensure ongoing stability and performance. Should you have any additional questions or require assistance, please contact our support team at https://helpdesk.kaseya.com/hc/en-gb#/contact Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

Reported by Kaseya on their status page.

1. resolvedAug 28 · 18:23 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 28 · 18:18 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 25 · 16:34 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. postmortemAug 25 · 15:20 UTC

   # Summary: Between 2026-07-03 11:41 UTC and 2026-07-03 15:09 UTC, some Autotask PSA customers hosted in the UK02 region experienced intermittent application performance degradation. Impacted customers may have encountered slow or unresponsive GUI behavior, widget timeout errors, and delays in workflow rule processing while queued workflow events were processed. # Root Cause: An intermittent hardware failure within the infrastructure supporting the UK02 environment caused unexpected database restarts. As a result, some application services experienced disrupted database connectivity, leading to intermittent application performance degradation and workflow processing delays until recovery actions were completed. ## Incident Timeline: * Identified: 2026-07-03 11:41 UTC * Public Notification: 2026-07-03 13:58 UTC * Resolved: 2026-07-03 15:09 UTC # Preventative Measures: To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. ### Enhancements to Infrastructure Resiliency * Review storage path failover configurations to improve resilience during intermittent connectivity events within redundant infrastructure paths. * Evaluate additional infrastructure resiliency improvements that may enhance automatic recovery during hardware connectivity failures. ### Enhancements to Application Resiliency * Improve application resilience to database connectivity interruptions to reduce service impact during infrastructure failover or recovery events. * Enhance automated recovery mechanisms so application services can restore normal operation more quickly following unexpected database disruptions. ### Enhancements to Incident Management and Response * Reinforce established incident response procedures across operational teams to ensure recovery actions are executed consistently and efficiently during similar events. * Provide additional cross-functional training to strengthen shared understanding of application and database interactions, enabling faster diagnosis and restoration of service.

Reported by Kaseya on their status page.

1. resolvedAug 24 · 18:02 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 22 · 14:50 UTC

   Changes made by the Kaseya R&D team have proven successful and full functionality has been restored. The issue is now considered resolved.

Reported by Kaseya on their status page.

1. resolvedAug 20 · 12:38 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 19 · 20:08 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. postmortemAug 19 · 15:27 UTC

   **\[Datto Endpoint Backup for PC\]**   **A performance degradation event affected the Datto Endpoint Backup for PC Server service, impacting service responsiveness and availability – 2026-07-31**  ‌ **Summary:** Between **2026-07-31 05:30 PM UTC** and **2026-08-05 07:30 PM UTC**, Datto Endpoint Backup for PC customers hosted on Cloud Siris 215069 encountered reduced performance and intermittent issues with offsite capabilities.     **Root Cause:**   The service interruption resulted from a hardware failure. Recovery activities were conducted with a focus on maintaining service integrity and minimizing potential impact. Following restoration of service, a review was completed and improvement actions have been identified to further enhance recovery processes.    **Incident Timeline:**   * Identified: **2026-07-31 05:30 PM UTC**   * Public Notification: **2026-07-31 05:34 PM UTC**   * Resolved: **2026-08-05 07:30 PM UTC**      **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps.   * Create standardized documentation for system restoration workflows and conduct process reviews with key technical and operational teams to ensure effective execution, knowledge sharing, and continuous improvement.  * Establish a centralized and well-documented catalog of monitoring alerts and designated response teams to improve operational visibility, accountability, and incident management.

Reported by Kaseya on their status page.

1. resolvedAug 18 · 14:13 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 18 · 04:26 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 14 · 19:32 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. resolvedAug 14 · 12:14 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. postmortemAug 12 · 19:57 UTC

   **Root Cause Analysis – VSA10 Intermittent Service Degradation Following 10.28 Release**  **Summary**  Between **2026-07-24 02:00 UTC** and **2026-07-24 20:25 UTC**, some customers using VSA10 experienced intermittent service degradation, including temporary agent connectivity issues, delayed agent check-ins, and HTTP 503 errors. During periods of elevated automation activity, affected agents could appear to repeatedly transition between online and offline states before reconnecting automatically. The issue was fully resolved on July 24, 2026.   **Root Cause**  A software change introduced in the 10.28 release altered how certain automation-related database operations were processed. Under high levels of concurrent automation activity, this change resulted in resource contention within the application environment, leading to intermittent service interruptions and delayed responses for agent communications. A hotfix was developed, tested, and deployed the same day to restore the previous transaction handling behavior and eliminate the contention condition.  **Incident Timeline**  * **Identified:** 2026-07-24 02:00 UTC  * **Public Notification:** 2026-07-24 13:27 UTC  * **Resolved:** 2026-07-24 20:25 UTC  **Preventative Measures**  To reduce the likelihood and impact of similar incidents in the future, we are implementing the following improvements:  **Enhancements to Monitoring and Alerting**  * Introduce additional monitoring and alerting for database contention and long-running transactions to further accelerate detection of similar conditions.  * Expand service health dashboards to further improve visibility into application response performance.  **Enhancements to Release Management Practices**  * Implement expanded canary deployment procedures for higher-risk platform changes, allowing updates to be validated on a limited subset of infrastructure before broader rollout, further reducing the risk for these deployments.  * Add additional review requirements for changes affecting high-volume agent communication paths, further reducing risk for these deployments.  **Enhancements to Validation and Testing**  * Strengthen load and concurrency testing for components that support large-scale automation activity, further increasing scalability at the time of deployment.  * Increase validation coverage for scenarios that simulate production-scale agent workloads to catch scalability issues prior to deployment, further reducing risk.  **Enhancements to Platform Resiliency**  * Continue development of automation workload distribution improvements designed to reduce concentrated processing spikes during large-scale task execution, further increasing scalability at the time of deployment.  * Review additional service isolation and capacity improvements to further reduce the impact of localized workload surges.  **Completed Corrective Action**  * The software change responsible for the contention condition was reverted through a hotfix deployed on July 24, 2026. Following deployment, monitoring confirmed that error rates returned to normal levels and no recurrence of the issue was observed.

Reported by Kaseya on their status page.

1. postmortemAug 12 · 19:46 UTC

   **Root Cause Analysis – DRMM Agent Services Incorrectly Flagged by Endpoint Security Software**  **Summary**  Between **2026-07-30 17:00 UTC and 2026-07-31 18:43 UTC**, some Datto RMM customers on the Syrah platform experienced issues following the deployment of agent version **15.1.0**. The issue affected endpoints utilizing **Sophos**, where certain DRMM agent services were identified as malicious. In affected environments, agent files were quarantined or removed, causing the Datto RMM agent to become non-functional until remediation actions were completed.  The issue affected a subset of customers and was resolved after coordination with the security vendor.  **Root Cause**  Following the deployment of DRMM agent version 15.1.0, certain agent components were incorrectly identified as malicious by a third-party endpoint security vendor. The detection was a false positive and was not the result of malware or unauthorized code within the DRMM agent. Investigation determined that the detection was likely related to changes in the digital signing reputation of the agent files, which caused the security tool to classify legitimate agent activity as suspicious.  **Incident Timeline**  * **Identified:** 2026-07-30 21:00 UTC  * **Public Notification:** 2026-07-31 02:27 UTC  * **Resolved:** 2026-07-31 18:43 UTC  **Preventative Measures**  To reduce the likelihood and impact of similar incidents in the future, we are implementing the following improvements:  **Enhancements to Release Validation**  * Further strengthen our pre-release validation by incorporating a broader set of security and threat-intelligence platforms before agent updates are broadly deployed.  * Broaden third-party endpoint security testing to further improve early detection of potential false-positive classifications before release.  **Enhancements to Vendor Coordination**  * Expand the existing file reputation submission process to include additional security providers to further improve coordination and response options, reducing reliance on a single vendor path.  * Establish more formalized engagement processes with security vendors to facilitate faster review and resolution of false-positive detections.  **Enhancements to Agent Deployment Practices**  * Evaluate staged agent rollout capabilities that would allow updates to be gradually deployed to a subset of endpoints before broader distribution limiting the scope of impact when issues are detected.  * Use phased deployments to identify unexpected environmental interactions earlier and further reduce potential customer impact.  **Enhancements to Agent Update Architecture**  * Review and improve elements of the agent update mechanism to reduce the likelihood that normal update activities are misinterpreted by security software.  * Continue refining update workflows to improve compatibility with modern endpoint protection technologies to further reduce the risk of false positive classifications

Reported by Kaseya on their status page.

1. resolvedAug 12 · 19:33 UTC

   This incident has been resolved.

Reported by Kaseya on their status page.

1. postmortemAug 12 · 13:29 UTC

   # Summary: Between 2026-07-28 14:53 UTC and 2026-07-29 14:38 UTC, Autotask customers hosted on zones AE01, AE02, AE03, AE04, AW01, AW02, AW03, AW04, PR01, LR01, ES01, AU01, and AU02 experienced a delay in inbound email ticket creation. # Root Cause: A configuration issue introduced during the deployment of a new environment resulted in unintended mailbox access conflicts, which unexpectedly interfered with normal email processing and delayed ticket creation from inbound emails. ## Incident Timeline: * Identified: 2026-07-28 15:12 UTC * Public Notification: 2026-07-28 18:01 UTC * Mitigated: 2026-07-28 18:06 UTC * Resolved: 2026-07-29 14:38 UTC # Preventative Measures: To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * **Enhancements to Release and Configuration Management**: We are strengthening our environment deployment process by introducing additional validation and review checkpoints for configuration settings before new environments are brought into service. * **Enhancements to Monitoring and Alerting**: We are implementing additional monitoring and alerting for email processing workflows to enable faster detection and response when abnormal error rates occur. * **Enhancements to Service Resiliency**: We are improving email processing workflow to ensure messages are easier to reprocess if processing failures occur, reducing the amount of time required to remediate mail processing problems in the future. * **Enhancements to Diagnostics and Troubleshooting**: We are expanding operational logging and diagnostic capabilities to provide greater visibility into processing failures and accelerate root cause identification and recovery efforts. * **Enhancements to Incident Response**: We have reviewed and refined our operational procedures and recovery processes to reduce restoration times and minimize customer impact during future incidents.

Reported by Kaseya on their status page.