Datto Outage History

Started Jun 30, 2026, 01:26 PM UTC· resolved Jul 15, 2026, 02:25 PM UTC

1. identified Jun 30, 2026, 01:26 PM UTC

   The Kaseya R&D Team identified the cause of the issue where Jobs intermittently fail to be created in the Web UI. The fix for the problem is currently being tested, and it is planned to be deployed in the coming days.

2. monitoring Jul 01, 2026, 10:20 AM UTC

   The fix has been implemented on both the Syrah and Vidal platforms.

3. resolved Jul 15, 2026, 02:25 PM UTC

   The 15.0.1 version that included the fix for this issue is live on all production platforms.

Read the full incident report →

Started Jun 29, 2026, 04:02 PM UTC· resolved Jul 15, 2026, 02:25 PM UTC

1. investigating Jun 29, 2026, 04:02 PM UTC

   We are aware of a problem where Datto RMM's 15.0.1 Cagservice.exe is being flagged as malicious (Rapidstop) by Microsoft Defender for Endpoint. The Kaseya R&D Team are investigating this issue. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. investigating Jun 29, 2026, 04:07 PM UTC

   We are continuing to investigate this issue.

3. identified Jun 29, 2026, 07:36 PM UTC

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

4. monitoring Jun 29, 2026, 10:47 PM UTC

   A fix has been implemented and we are monitoring the results.

5. resolved Jul 15, 2026, 02:25 PM UTC

   This incident has been resolved.

6. postmortem Jul 16, 2026, 08:47 AM UTC

   ## **Summary** On 29 June 2026, following a third-party security intelligence definition update, a component of the Datto RMM agent was incorrectly identified as malicious on certain devices. As a result, affected Datto RMM agents stopped functioning as expected, causing affected devices to appear offline within the Datto RMM portal. Kaseya promptly investigated the issue, engaged with the third-party provider, and worked collaboratively to resolve the misclassification. Updated security intelligence definitions were subsequently released, resulting in misclassification no longer occurring on devices already updated with the new definitions. Based on the investigation, this incident was determined to be the result of a false positive detection and was not caused by actual malware or ransomware activity. ### **Customer Impact Assessment** Affected customers may have experienced: * Devices appearing offline within the Datto RMM portal. * Complete interruption in agent-based management activities. * Visibility and management capabilities for affected endpoints through Datto RMM were inhibited during the incident. Manual intervention was required on affected devices to restore agent functionality. ## **Root Cause** The incident was caused by a false positive security detection generated by a third-party security product, which incorrectly identified legitimate Datto RMM software activity as malicious. While we wait for the technical RCA from the third-party provider for a formal root cause for the false positive detection, the issue was resolved through the updated security intelligence definitions that corrected the classification. Based on the investigation, the Datto RMM software involved in this event functioned as designed and was not determined to be the source of the false positive detection. The review also identified opportunities to strengthen pre-release validation and incident response processes to better detect and respond to similar third-party security classification issues. ## **Incident Timeline** ## **Lessons Learned** This incident highlighted the importance of close coordination with security vendors and the need for continued validation of software releases against evolving security detection mechanisms. The review also reinforced the importance of rapid escalation, vendor collaboration, and timely customer communications when addressing false positive detections. ### **Preventative Measures** To reduce the likelihood and impact of similar incidents in the future, Kaseya is implementing the following improvements: #### **Proactive Vendor Collaboration** We are strengthening collaboration with security vendors to improve pre-release validation and reduce the likelihood of false positive detections affecting customers. #### **Enhanced Release Validation** We are expanding release validation procedures to include additional security compatibility testing across representative customer environments. #### **Enhanced Monitoring** We are improving monitoring and alerting capabilities to more quickly identify and assess abnormal security detections involving Datto RMM software. #### **Enhanced Response Procedures** We are updating incident response processes to accelerate investigation, vendor engagement, and customer communications when similar events occur.

Read the full incident report →

Started Jun 19, 2026, 11:21 AM UTC· resolved Jun 19, 2026, 12:31 PM UTC

1. investigating Jun 19, 2026, 08:51 AM UTC

   We are currently investigating an issue where partners are unable to access the Workplace portal. Partners in EU Cell 4, EU Cell 7, and EU Cell 16 are experiencing service disruptions and may receive a 404 Error when attempting to access the portal. Our engineering team is actively investigating the issue and working to restore service as quickly as possible.

2. investigating Jun 19, 2026, 08:56 AM UTC

   We are continuing to investigate this issue.

3. monitoring Jun 19, 2026, 09:01 AM UTC

   A fix has been implemented and we are monitoring the results.

4. monitoring Jun 19, 2026, 11:21 AM UTC

   Customers may still experience a delay in email processing while the service is catching up with the queue that formed during the incidents.

5. resolved Jun 19, 2026, 12:31 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 19, 2026, 10:03 AM UTC· resolved Jun 19, 2026, 01:22 PM UTC

1. investigating Jun 19, 2026, 10:03 AM UTC

   The INKY R&D Team is investigating the issue where emails to internal recipients filtered through INKY are not showing up in INKY and not getting delivered to recipients. Emails to external recipients, while also not appearing in INKY, successfully get delivered but with a noticeable delay. Please subscribe to this incident to receive update notifications as they become available.

2. identified Jun 19, 2026, 10:22 AM UTC

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

3. monitoring Jun 19, 2026, 10:30 AM UTC

   A fix has been implemented and we are monitoring the results.

4. monitoring Jun 19, 2026, 12:33 PM UTC

   The service has caught up with processing through items queued in INKY, and the R&D team is reviewing individual examples of residual issues . Please work with our support team and provide them with message IDs for review if the issue appears to still persist.

5. resolved Jun 19, 2026, 01:22 PM UTC

   This incident has been resolved.

6. postmortem Jul 01, 2026, 03:53 PM UTC

   **Inky Public Root Cause Analysis** **EU Central Email Processing Delay** **Summary** On the date of the incident, Inky experienced a disruption to email processing within the EU Central region. Increased inbound email volume coincided with a failure of infrastructure autoscaling, preventing additional processing capacity from being automatically provisioned. As a result, email messages queued for processing and experienced delivery delays. Service was restored after infrastructure capacity was manually increased, allowing queued messages to be processed and normal throughput to resume. **Customer Impact** Customers whose email traffic was processed through the EU Central region experienced delays in email analysis and delivery. **Impact Details** * Service affected: Email Processing * Region affected: EU Central * Impact start: 08:15 UTC * Service restoration: 10:00 UTC * Total duration: Approximately 105 minutes * Maximum observed delay: Up to approximately 90 minutes for some messages No customer data was lost during the incident. Queued messages were retained and processed once capacity was restored. **What Happened** During a normal increase in email traffic, the platform required additional processing capacity. The automatic scaling mechanism responsible for adding resources did not successfully provision additional servers due to a configuration issue within the scaling configuration. Because additional capacity was not added as expected, processing resources became constrained and email messages began accumulating in processing queues, resulting in delivery delays. **Resolution** The operations team investigated the processing delays and determined that additional processing capacity was required. Infrastructure resources in the affected region were manually scaled to meet demand. As the additional resources came online, queue depth decreased and processing throughput returned to normal levels. All queued messages were subsequently processed and delivered. **Root Cause** The incident was caused by a configuration condition within the autoscaling setup that prevented automatic expansion of processing capacity when demand increased. A previous capacity adjustment increased the desired resource level but did not include a corresponding increase to the maximum scaling limit. When additional capacity was required, the autoscaling process was unable to complete the scale-up operation, preventing new resources from being added automatically. **Preventative Actions** To reduce the likelihood of similar incidents, the following corrective actions are being implemented: 1. **Improve autoscaling configuration safeguards** 1. Infrastructure templates are being updated so scaling limits are automatically aligned with required capacity settings, reducing the possibility of configuration mismatches. 1. **Enhance monitoring and alerting** 1. New monitoring will directly detect and alert on autoscaling failures, enabling faster identification and response when scaling operations do not complete successfully. 1. **Accelerate operational response** 1. Alerting and operational procedures will be updated to provide faster, more direct mitigation guidance when autoscaling failures occur. **Final Status** The issue has been fully resolved, and normal email processing operations have been restored. Additional monitoring and infrastructure improvements are being implemented to strengthen resiliency and improve detection of similar conditions in the future. **Incident Duration:** 08:15 UTC – 10:00 UTC \(105 minutes\)` `**Affected Service:** Inky Email Processing \(EU Central Region\)

Read the full incident report →

Started Jun 17, 2026, 03:27 PM UTC· resolved Jul 01, 2026, 08:46 PM UTC

1. investigating Jun 17, 2026, 03:27 PM UTC

   We are aware that some customers are continuing to experience difficulty accessing certain applications, including Microsoft Teams, following a recent Datto EDR update. We are actively investigating and treating this as a priority. What we currently know: A recent Datto EDR update enabled additional behavioral monitoring on affected endpoints. We have identified this change as a contributing factor to the issue and are working on a resolution. What you can do right now: A reboot of the affected endpoint may resolve the issue in some cases. Our team is also working on a scripted remediation and a hotfix — we will update this page as those become available. What we are doing: Our engineering team is actively working on a fix. Subscribe to updates at status.kaseya.com to be notified as our investigation progresses.

2. identified Jun 18, 2026, 07:39 PM UTC

   If you are still experiencing issues after rebooting, please contact Kaseya Support to receive a script that can be run on affected endpoints to resolve the issue. A hotfix agent update is in progress and will be released shortly. We will update this page once it is available.

3. monitoring Jun 19, 2026, 12:33 AM UTC

   We’re pleased to inform you that our Engineering team has released a Hotfix for the Datto AMSI module remaining on devices: UI 15272 Agent #3.17.1.5552 Fixes: This release addresses an issue where the Datto AMSI provider remained actively registered on a device after having the AMSI module disabled. The AMSI module remains disabled globally and will be reintroduced through a controlled rollout. This change does not disable overall EDR protection. It is a temporary mitigation specific to the AMSI module. This page provides information to assist with determining the agent version on a device: https://edr.datto.com/help/Content/troubleshooting/confirming-ui-version.htm

4. resolved Jul 01, 2026, 08:46 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 15, 2026, 02:12 PM UTC· resolved Jun 24, 2026, 06:44 PM UTC

1. investigating Jun 15, 2026, 02:12 PM UTC

   We are aware of a problem where a subset of Endpoint Backup v2 assets can experience a backup failure due to a "Errors writing to the AOF file: Input/output" error. The Kaseya R&D Team is investigating the issue and working towards a resolution. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. investigating Jun 15, 2026, 05:31 PM UTC

   We are continuing to investigate this issue.

3. identified Jun 16, 2026, 06:45 PM UTC

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

4. identified Jun 23, 2026, 05:53 PM UTC

   We’re pleased to share that our team will begin rolling out the fix to non-U.S. regions on June 23, 2026 at 06:00 PM UTC, followed by deployment to U.S. regions on June 24, 2026 at 08:00 AM UTC. We appreciate your patience as we work to ensure a smooth and reliable update experience for all customers.

5. monitoring Jun 24, 2026, 01:24 PM UTC

   A fix has been implemented and we are monitoring the results.

6. resolved Jun 24, 2026, 06:44 PM UTC

   This incident has been resolved.

7. postmortem Jul 24, 2026, 02:21 PM UTC

   **Endpoint Backup v2 - Backup Failures Due To 'EOF' Error – 2026-06-15** ‌ **Summary:** Between **2026-06-15 12:30 PM UTC** and **2026-06-24 09:00 AM UTC**, a subset of Endpoint Backup V2 users experienced intermittent backup failures due to an “EOF” error. **Root Cause:** A rare compatibility issue within the underlying storage infrastructure caused some storage servers to become unresponsive, which in turn delayed or prevented backup operations from completing successfully. Engineering developed and deployed a targeted fix using a phased rollout approach to validate effectiveness and minimize risk. Following successful verification, the update was deployed across all affected storage servers, fully resolving the issue. **Incident Timeline:** * Identified: 2026-06-15 12:30 PM UTC * Public Notification: 2026-06-15 03:12 PM UTC * Resolved: 2026-06-24 09:00 AM UTC

Read the full incident report →

Started Jun 12, 2026, 07:57 PM UTC· resolved Jun 15, 2026, 05:06 PM UTC

1. identified Jun 12, 2026, 07:57 PM UTC

   We are aware of a problem where a subset of Endpoint Backup v2 assets can experience a backup failure due to error "system.ntfs_reparse_data: invalid argument". The Kaseya R&D Team has identified the issue and is working towards a resolution. In the meantime our Support team has been supplied with a workaround and can assist you with implementing it. If you would like to have the workaround applied, please create a ticket with our Support team or contact them at 833-863-2237. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Jun 15, 2026, 01:29 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jun 15, 2026, 05:06 PM UTC

   This incident has been resolved.

4. postmortem Jul 21, 2026, 06:47 PM UTC

   **Endpoint Backup v2 - Subset of Endpoint Backup v2 Assets Experienced Backup Failures Due to a "system.ntfs\_reparse\_data: invalid argument" error –2026-06-12** **Summary:** Between **2026-06-12 01:00 PM UTC** and **2026-06-15 08:00 PM UTC**, Endpoint Backup v2 customers experienced an issue where a subset of Endpoint Backup v2 assets experienced failed backups due to error "system.ntfs\_reparse\_data: invalid argument". **Root Cause:** After the 1.14 agent release, we identified a compatibility issue involving certain third-party components that resulted in backup failures for a subset of customers. We quickly applied a temporary workaround, released a permanent fix, and then removed the workaround once the fix was in place. The issue has been resolved, and backup operations are functioning normally. **Incident Timeline:** * Identified: **2026-06-12 01:00 PM UTC** * Public Notification: **2026-06-12 08:57 PM UTC** * Resolved: **2026-06-15 08:00 PM UTC** **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * To prevent similar issues in the future, we have implemented a whitelist-based approval process for symlink support, providing additional controls and reducing the likelihood of recurrence.

Read the full incident report →

Started Jun 10, 2026, 09:10 PM UTC· resolved Jun 11, 2026, 11:16 PM UTC

1. investigating Jun 10, 2026, 09:10 PM UTC

   We are investigating an issue causing Endpoint Backup v2 assets to appear offline in UniView. While this issue is ongoing, scheduled backups are not running, recovery points may show as unavailable, and backup, restore, and BMR operations are failing. All regions are affected. There is no workaround available at this time. The Kaseya R&D team is engaged and actively investigating, and we will provide updates as more information becomes available. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jun 11, 2026, 08:32 AM UTC

   The R&D team identified the issue, and developed a fix. The change is currently being tested before proceeding with the rollout to production.

3. identified Jun 11, 2026, 10:03 AM UTC

   The hotfixed agent version is being rolled out to production following successful testing and validation that the changes implemented by the R&D team resolves the issue. We are deploying the upgrade in batches to mitigate any risks to the health of the infrastructure.

4. identified Jun 11, 2026, 11:32 AM UTC

   We are continuing the rollout of the fixed agent version to production.

5. identified Jun 11, 2026, 04:43 PM UTC

   We are continuing to work on a fix for this issue.

6. resolved Jun 11, 2026, 11:16 PM UTC

   This incident has been resolved. The fixed agent version has been rolled out to production, and Endpoint Backup v2 services have been restored. Assets are reporting correctly in UniView, and backup, restore, BMR, and agent registration operations are functioning as expected. Scheduled backups have resumed and will run at their next scheduled time. We will continue to monitor the environment to ensure ongoing stability. If you continue to experience any issues, please contact Kaseya Support. We sincerely apologize for the disruption and thank you for your patience while we worked to resolve this issue.

7. postmortem Jun 25, 2026, 07:49 PM UTC

   **Endpoint Backup v2 - All Endpoints Report Offline Status – 2026-06-10** **Summary:** Between **2026-06-10 20:48 PM UTC** and **2026-06-11 21:14 PM UTC**, Endpoint Backup v2 customers experienced an issue where assets appeared offline in UniView affecting scheduled backups, recovery point availability, as well as causing backup, restore, and BMR operations to be fail. **Root Cause:** As part of a recent agent update, we released improvements intended to add new functionality and enhance system efficiency. However, this change introduced an issue that caused the system to open and maintain more connections than expected. This led to increased strain on our infrastructure, ultimately impacting overall system performance and availability. **Incident Timeline:** * **Identified:** 2026-06-10 20:48 PM UTC * **Public Notification:** 2026-06-10 21:10 PM UTC * **Resolved:** 2026-06-11 21:14 PM UTC **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * We are enhancing our system to automatically adjust capacity during periods of increased demand. This improvement will help ensure more consistent performance and a more reliable experience for our customers. * We are improving the stability and performance of our service to deliver a smoother experience. These enhancements will strengthen connection reliability, help the system continue working seamlessly if network conditions change, and optimize how our service handles requests to reduce slowdowns or disruptions.

Read the full incident report →

Started Jun 10, 2026, 03:44 PM UTC· resolved Jun 10, 2026, 08:28 PM UTC

1. identified Jun 10, 2026, 03:44 PM UTC

   We are aware of a problem where BCDR users paired to Server5673 can experience degraded offsite capabilities. The Kaseya R&D Team has identified the issue and is working towards a resolution. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Jun 10, 2026, 06:59 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jun 10, 2026, 08:28 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 10, 2026, 12:43 AM UTC· resolved Jun 10, 2026, 03:45 AM UTC

1. investigating Jun 10, 2026, 12:43 AM UTC

   We are experiencing a issues with outbound email on US-VSA146. Our team is working to restore functionality on the instance at this time. We apologize for any inconvenience. - Kaseya Cloud Operations Team

2. monitoring Jun 10, 2026, 02:04 AM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jun 10, 2026, 03:45 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 08, 2026, 01:31 PM UTC· resolved Jul 20, 2026, 05:00 PM UTC

1. investigating Jun 08, 2026, 01:31 PM UTC

   We are aware of a problem where some customers hosted on pod 'gbe2-saas-p1' are experiencing backup performance degradation for some SharePoint services. The Kaseya R&D Team is actively Investigating the issue. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jun 08, 2026, 03:37 PM UTC

   The backup cadence on pod 'gbe2‑saas‑p1' has been temporarily set to 2x daily backups to maintain high success rates. The 3x daily backup cadence will be restored once it is stable and reliable for all customers. The Kaseya R&D Team will continue to monitor pod performance.

3. identified Jun 09, 2026, 01:19 PM UTC

   Backup success rate metrics for SharePoint and Teams services on pod 'gbe2-saas-p1' are improving and our R&D team is continuing to monitor pod performance as it recovers.

4. monitoring Jun 10, 2026, 12:48 PM UTC

   Backup success rate metrics for SharePoint and Teams services on pod 'gbe2-saas-p1' have returned to normal and our R&D team is continuing to monitor for any other issues.

5. monitoring Jun 10, 2026, 02:40 PM UTC

   All backups continue to process normally on pod 'gbe2‑saas‑p1' while the backup cadence remains temporarily set to 2x daily backups to maintain high backup success rates. The 3x daily backup cadence will be restored once it is stable and reliable for all customers.

6. monitoring Jun 11, 2026, 07:46 PM UTC

   SharePoint and Teams backup success rates on pod 'gbe2-saas-p1' continue to remain stable at 2x backups per day. Our R&D team is continuing to monitor and the 3x daily backup cadence will be restored once it is stable and reliable for all customers.

7. monitoring Jun 15, 2026, 03:00 PM UTC

   The backup cadence on pod 'gbe2‑saas‑p1' remains temporarily set to 2x daily backups to maintain high success rates amid Microsoft throttling. Backups are running normally and success rate metrics remain stable. The 3x daily backup cadence will be restored once it is stable and reliable for all customers.

8. monitoring Jun 23, 2026, 06:31 PM UTC

   The backup cadence for pod ‘gbe2‑saas‑p1’ is still temporarily set to 2x backups per day. Backups are running normally and backup success rates remain stable. Our R&D team will increase backup cadence to 3x backups per day once it’s safe and reliable for all customers on the pod.

9. monitoring Jul 02, 2026, 06:31 PM UTC

   The backup cadence for pod ‘gbe2‑saas‑p1’ is still temporarily set to 2x backups per day and backup success rates remain stable. Our R&D team has finished deploying additional improvements to further address the issue and they are actively monitoring the results. Backup cadence will be reverted to 3x daily backups as soon as it is safe and reliable for all customers hosted on the pod.

10. monitoring Jul 17, 2026, 08:03 PM UTC

    The backup cadence on pod 'gbe2-saas-p1' has been restored to 3x daily backups and all services are currently processing new backups normally. Our R&D team is closely monitoring for any issues.

11. resolved Jul 20, 2026, 05:00 PM UTC

    This incident has been resolved.

Read the full incident report →

Started Jun 05, 2026, 02:38 PM UTC· resolved Jun 05, 2026, 03:58 PM UTC

1. identified Jun 05, 2026, 02:38 PM UTC

   We are aware of a problem where Datto SaaS Protection Partners are currently unable to onboard new customers within the Partner Portal and are receiving an error. The Kaseya R&D Team has identified the issue and they are actively working on a fix. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jun 05, 2026, 03:19 PM UTC

   A fix for this issue has been tested and is being prepared for release.

3. monitoring Jun 05, 2026, 03:47 PM UTC

   A fix for the issue has been deployed and the SaaS Protection onboarding service has been restored.

4. resolved Jun 05, 2026, 03:58 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 04, 2026, 07:55 AM UTC· resolved Jun 04, 2026, 02:00 PM UTC

1. investigating Jun 04, 2026, 07:55 AM UTC

   We are aware of a problem where error messages are being experienced when navigating the Autotask PSA UI. The Kaseya R&D Team is actively investigating this behaviour. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jun 04, 2026, 10:04 AM UTC

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

3. identified Jun 04, 2026, 10:35 AM UTC

   Thank you for your patience while we continue to work on a fix for this issue. A workaround to prevent the error messages has been confirmed. If you navigate within Autotask to the top right-hand corner: My Account > My Settings > Reset Settings Please note that when applying this change, many of your current settings will be reset. This includes certain column choosers, notification template defaults, search grid default criteria, and default checkbox/radio button selections.

4. monitoring Jun 04, 2026, 01:12 PM UTC

   A fix has been implemented and we are monitoring the results.

5. resolved Jun 04, 2026, 02:00 PM UTC

   This incident has been resolved.

6. postmortem Jul 02, 2026, 01:55 PM UTC

   # Summary: Between 2026-06-04 05:30 UTC and 2026-06-04 12:00 UTC, some customers experienced intermittent error messages when navigating the Autotask PSA user interface, which impacted their ability to view certain tickets. # Root Cause: A recent product release \(version 2026.3\) introduced a defect that caused an error to appear under specific ticket grid and data configurations. # Incident Timeline: * Identified: 2026-06-04 07:00 UTC * Public Notification to the Status Page: 2026-06-04 07:55 UTC * Workaround posted to the Status Page: 2026-06-04 10:35 UTC * Resolved: 2026-06-04 13:00 UTC # Preventative Measures: To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps: * **Enhancements to Software Delivery Practices:** * Expand regression test coverage for ticket-related workflows impacted by code changes * Introduce additional validation checks for optional or missing data scenarios prior to release * Require clearer developer and QA documentation of tested scenarios for all bug fixes * **Enhancements to Quality Assurance:** * Add targeted test cases for edge conditions involving incomplete or non-standard ticket configurations * Improve automated test coverage around UI data validation paths

Read the full incident report →

Started Jun 03, 2026, 01:42 PM UTC· resolved Jun 24, 2026, 01:32 PM UTC

1. identified Jun 03, 2026, 01:42 PM UTC

   We are aware of a problem where Datto Endpoint Backup for PC users paired to Cloud Siris 246891 in the US East region can experience degraded offsite performance. The Kaseya R&D Team has identified the issue and is working towards a resolution. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jun 15, 2026, 12:47 PM UTC

   We are continuing to work on a fix for this issue.

3. resolved Jun 24, 2026, 01:32 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 03, 2026, 11:25 AM UTC· resolved Jun 03, 2026, 02:32 PM UTC

1. investigating Jun 03, 2026, 11:25 AM UTC

   We are aware of a problem where customers are unable to onboard new tenants. The status page within the Datto Partner Portal is also unavailable and returning a 500 error. The Kaseya R&D Team is actively working to address the problem. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jun 03, 2026, 12:42 PM UTC

   Our R&D team has identified the issue and are actively working to deploy a fix.

3. monitoring Jun 03, 2026, 01:51 PM UTC

   A fix to restore access to the SaaS Protection Status Page within the Partner Portal and Onboarding functionality has been implemented. Our R&D team is actively monitoring for any other issues.

4. resolved Jun 03, 2026, 02:32 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 29, 2026, 06:14 PM UTC· resolved Jun 01, 2026, 12:25 PM UTC

1. investigating May 29, 2026, 06:14 PM UTC

   We are aware of a problem where customers hosted on node 'use1-bfyii-126' are experiencing a disruption to their SaaS Protection services. The Kaseya R&D Team is actively investigating. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring May 29, 2026, 06:55 PM UTC

   Our R&D team has implemented a fix to restore services on node 'use1-bfyii-126' and they are actively monitoring.

3. resolved Jun 01, 2026, 12:25 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 27, 2026, 01:33 PM UTC· resolved May 28, 2026, 05:09 PM UTC

1. identified May 27, 2026, 01:33 PM UTC

   We are aware of a problem where the last backup timestamp for Endpoint Backup v2 assets can fail to update correctly, which may result in false-positive backup threshold alerts within UniView. Please note that this issue does not impact backup performance and is limited to a visual display anomaly only. The Kaseya R&D Team has identified the issue and is working towards a resolution. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring May 27, 2026, 08:22 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved May 28, 2026, 05:09 PM UTC

   This incident has been resolved.

4. postmortem Jun 04, 2026, 06:29 PM UTC

   **Endpoint Backup v2 - Last Backup Timestamp Is Not Updating Correctly, Which May Result in False-Positive Backup Threshold Alerts within UniView – 2026-05-27** **Summary:** Between **2026-05-27 13:36 UTC** and **2026-05-28 18:09 UTC**, Endpoint Backup v2 customers experienced an issue where the last backup timestamp for Endpoint Backup v2 assets can fail to update correctly, which may result in false-positive backup threshold alerts within UniView. **Root Cause:** A large number of backup messages built up in the system faster than they could be processed. As a result, backup updates were delayed by several days. This caused outdated “last backup” timestamps and triggered incorrect backup alerts for multiple partners. **Incident Timeline:** * Identified: 2026-05-27 13:36 UTC * Public Notification: 2026-05-27 14:33 UTC * Resolved: 2026-05-28 18:09 UTC **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * Implemented configuration updates and performance improvements to better handle expected activity levels, moving beyond previous default settings to support a higher workload more effectively. * Enhanced our monitoring with improved alerts to quickly detect and address any unusual build-up in processing queues.

Read the full incident report →

Started May 26, 2026, 05:36 PM UTC· resolved May 27, 2026, 05:33 PM UTC

1. identified May 26, 2026, 05:36 PM UTC

   We are aware of a problem where online BCDR devices are reporting as offline through the Datto Continuity integration on our Vidal platform. The Kaseya R&D Team have identified the issue and are working on a fix Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified May 27, 2026, 10:33 AM UTC

   We are continuing to work on a fix for this issue.

3. monitoring May 27, 2026, 03:34 PM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved May 27, 2026, 05:33 PM UTC

   This incident has been resolved.

5. postmortem Jul 17, 2026, 09:16 AM UTC

   ## **Summary** Following the 15.0 upgrade, partners on the Vidal platform experienced an issue where Datto Continuity devices integrated into Datto RMM were incorrectly reported as offline. After identifying the root cause, the issue was mitigated on 27th May 2026, restoring normal service. A permanent fix is scheduled for the 15.0.1 release, targeted for completion by the end of June 2026. ## **Root Cause** The R&D team determined that, following a migration from a legacy backend service, communication between the Datto Continuity and Datto RMM services encountered exceptions when storage information was missing from the device data returned by the Continuity service. These exceptions caused the payload processing to fail, resulting in affected devices being incorrectly displayed as offline in Datto RMM. As a mitigation, the Datto Continuity Integration was reverted to the legacy backend service, which restored expected behavior. The R&D team is currently updating the processing logic to ensure missing data is handled gracefully, allowing valid data in the response to continue being processed. ## **Incident Timeline** ## **Preventative Measures** To reduce the likelihood and impact of similar incidents in the future, we are implementing the following actions: ### **Enhanced Monitoring and Alerting** The R&D team is implementing targeted monitoring and alerting for device synchronization failures, particularly when synchronization tasks remain queued for abnormal durations. These alerts will enable teams to proactively identify and respond to issues with Datto Continuity device synchronization, reducing the potential for partner impact.

Read the full incident report →

Started May 24, 2026, 05:52 PM UTC· resolved May 28, 2026, 06:15 PM UTC

1. investigating May 24, 2026, 05:52 PM UTC

   We are aware of a problem causing a disruption to services for Datto SaaS Protection customers hosted on pod 'gbe2-saas-p1'. Our R&D team has identified the issue and is actively working to resolve it. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified May 26, 2026, 01:16 PM UTC

   Our R&D team is continuing to address the current disruption to SaaS Protection services affecting customers hosted on pod 'gbe2-saas-p1'.

3. monitoring May 26, 2026, 03:43 PM UTC

   Our R&D team has implemented changes to address the issue affecting customers hosted on pod 'gbe2-saas-p1' and they are monitoring the results.

4. monitoring May 26, 2026, 08:11 PM UTC

   Backup success rate metrics on pod 'gbe2-saas-p1' are returning to normal. Our R&D team is continuing to monitor for any other issues.

5. monitoring May 27, 2026, 03:32 PM UTC

   Backup success rate metrics on pod 'gbe2-saas-p1' have returned to normal and our R&D team is continuing to monitor for any other issues.

6. resolved May 28, 2026, 06:15 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 23, 2026, 06:51 PM UTC· resolved May 23, 2026, 08:04 PM UTC

1. investigating May 23, 2026, 06:51 PM UTC

   We are aware of a problem where DSE subscribers are being rejected from SafeCheck on May 23, 2026. This seems to be a trending outage with multiple partners due to an API issue. The Kaseya R&D Team are currently investigating. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring May 23, 2026, 07:41 PM UTC

   The Datto Networking R&D team has implemented a fix that is believed to have resolved the issue. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

3. resolved May 23, 2026, 08:04 PM UTC

   Original reporters have confirmed the issue has been resolved after Engineering fix

Read the full incident report →

Started May 22, 2026, 09:37 AM UTC· resolved May 22, 2026, 11:30 AM UTC

1. investigating May 22, 2026, 09:37 AM UTC

   Our payment provider has flagged an ongoing issue that could potentially affect transaction processing. We are closely monitoring this and will post an update as soon as the situation is resolved or if any impact is detected. Thank you for your patience.

2. identified May 22, 2026, 10:23 AM UTC

   Vendor updated that they are currently experiencing American Express transaction failures due to maintenance activity within the American Express network, which extended beyond its planned duration. Vendor is actively working with the American Express team to minimize the impact and prevent additional processing failures while the maintenance is underway. Where possible, we recommend using alternative card brands for new transactions. Merchants may also retry failed American Express transactions after maintenance is complete. We will continue to monitor the situation closely and provide another update as soon as the issue is fully resolved.

3. resolved May 22, 2026, 11:30 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 21, 2026, 08:50 AM UTC· resolved May 26, 2026, 01:24 PM UTC

1. investigating May 21, 2026, 08:50 AM UTC

   Our R&D team is currently investigating the issue with the Datto Workplace and Datto File Protection portals in the US region being inaccessible at present. The top level URLs being currently inaccessible, customers in other regions can only access the login page through the subdomains. Please subscribe to this post to receive updates as our efforts to resolve this issue progresses. We apologise for the inconvenience caused!

2. monitoring May 21, 2026, 09:05 AM UTC

   The R&D team has successfully mitigated the issue and the previously affected pages are accessible again. We continue to monitor the health of the service while reviewing avenues to minimize the risk of the issue reoccurring.

3. resolved May 26, 2026, 01:24 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 20, 2026, 10:51 PM UTC· resolved Jun 02, 2026, 10:29 AM UTC

1. investigating May 20, 2026, 04:28 PM UTC

   We are aware of a problem where the Datto RMM's "cagservice.exe" is being flagged as malicious by some antivirus software, causing it to be quarantined. The Kaseya R&D Team are investigating the issue. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. investigating May 20, 2026, 07:05 PM UTC

   The RMM agent underwent an update, causing some devices with antivirus software, mainly Microsoft Defender for Endpoint, to alert on the update behavior and quarantine "cagservice.exe". This alert has been identified as a false positive. To prevent these alerts on Microsoft Defender for Endpoint for this new RMM agent, please follow these steps: 1. Go to the Security Portal 2. Go to Settings 3. Go to Endpoints 4. Under "Rules" click on "Indicators" 5. Under the file hashes, add the indicator with the SHA256 Hash: "91774f1195ba7042293bba1152afc334052d6c235a90e715f8c5c5fc8f27b089", and set the expiration to never, and the action to "Allow" 6. Allow time for the indicator to sync to endpoints. For more information on these steps, please see this Microsoft article: https://learn.microsoft.com/en-us/defender-endpoint/indicator-manage?source=recommendations The Kaseya R&D team is continuing to investigate this issue.

3. investigating May 20, 2026, 10:51 PM UTC

   In collaboration with Microsoft, an update has been made to Defender for Endpoint's security intelligence to prevent these false positive alerts on the cagservice.exe for devices running Microsoft's Defender for Endpoint. Devices running security intelligence version 1.451.15.0 and above have the updated detection logic. If you receive an alert for the cagservice.exe and your device is on version 1.451.150 and above, please reach out to our support team so we can continue to troubleshoot the issue. The Kaseya R&D Team is now investigating how to restore devices taken offline by the quarantine of the cagservice.exe.

4. identified May 21, 2026, 09:35 AM UTC

   The R&D team continues to work with Microsoft counterparts on a path to restore the erroneously quarantined assets, and restore RMM connectivity to affected devices.

5. monitoring May 21, 2026, 03:40 PM UTC

   The Kaseya R&D team confirmed with Microsoft counterparts that the issue was caused by misclassification of the 15.0 Datto RMM version's cagservice.exe in a recent security intelligence update for Microsoft Defender Antivirus and other Microsoft antimalware. This issue was fixed in the security intelligence update version 1.451.15.0, and the issue should no longer occur as long as the device is on this definition version or later. While our team works with Microsoft to understand if automatic remediation for devices where the quarantining occurred is feasible, we suggest manual intervention in order to bring affected devices online in Datto RMM. We recommend our partners to ensure that devices are updated with security intelligence update version 1.451.15.0 or later to avoid the agent being falsely flagged as malicious by Microsoft antimalware.

6. resolved Jun 02, 2026, 10:29 AM UTC

   With the general availability of the 15.0 release version of Datto RMM, we're resolving this informational post.

Read the full incident report →

Started May 20, 2026, 03:53 PM UTC· resolved May 20, 2026, 05:57 PM UTC

1. investigating May 20, 2026, 03:53 PM UTC

   We are aware of a problem where U.S. based Datto Workplace and Datto File Protection agents can experience intermittent connectivity failures and degraded access to the Portal. The Kaseya R&D Team is currently investigating the issue and working towards a resolution. Please note: File access and file downloads can be obtained through the File Explorer option. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring May 20, 2026, 05:43 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved May 20, 2026, 05:57 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 18, 2026, 08:15 PM UTC· resolved May 21, 2026, 01:22 PM UTC

1. identified May 18, 2026, 08:15 PM UTC

   We are aware of a problem where some Datto SaaS Protection customers hosted on pod 'des1-saas-p0' may experience degraded SharePoint/Teams backup performance. The Kaseya R&D Team has identified the issue and are actively working to resolve it. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring May 18, 2026, 10:25 PM UTC

   Our R&D team has implemented changes to address the SharePoint/Teams backup performance degradation affecting some customers on pod 'des1-saas-p0' and they are monitoring the results.

3. monitoring May 19, 2026, 12:32 PM UTC

   Backup success rate metrics for SharePoint/Teams services on pod 'des1-saas-p0' have returned to normal. Our R&D team is continuing to monitor.

4. resolved May 21, 2026, 01:22 PM UTC

   This incident has been resolved.

Read the full incident report →