Datto Outage History

Started Apr 10, 2026, 02:12 AM UTC· resolved Apr 10, 2026, 04:01 AM UTC

1. investigating Apr 10, 2026, 02:12 AM UTC

   We are currently investigating impacted performance and access to Kaseya Quote Manager across all regions. Thank you for your patience as work to resolve this. We will share an update as soon as it is available.

2. monitoring Apr 10, 2026, 02:51 AM UTC

   Our development team has implemented a fix and we are monitoring the results to ensure no further impact.

3. monitoring Apr 10, 2026, 02:52 AM UTC

   We are continuing to monitor for any further issues.

4. resolved Apr 10, 2026, 04:01 AM UTC

   We have confirmed all systems are now functional.

5. postmortem Apr 10, 2026, 04:29 PM UTC

   **Summary**: Between 2026-04-09T 22:15 UTC and 2026-04-10T 02:25 UTC, a small percentage of KQM customers experienced repeated gateway errors, slow loading across all pages, unexpected session expirations, and inability to save updates to quotes. **Root Cause**: This issue was caused by an unexpected spike in traffic into Kaseya Quote Manager **Incident Timeline**: * Impact start time: 2026-04-09T 22:15 UTC * Identified: 2026-04-10T 01:15 UTC * Public Notification to the Status Page: 2026-04-10T 02:12 UTC * Resolved: 2026-04-10T 02:25 UTC **What we’re doing about it**: * Faster detection: Enhancements to monitoring and alerting so issues like this are caught sooner. * Infrastructure resilience: Platform-level changes to ensure future unexpected traffic spikes do not impact the broader platform.

Read the full incident report →

Started Apr 09, 2026, 06:00 PM UTC· resolved Apr 10, 2026, 06:21 PM UTC

1. investigating Apr 09, 2026, 06:00 PM UTC

   We are aware of a problem where Datto Backup for Microsoft Azure and Datto Endpoint Backup with Disaster Recovery devices can experience registration failures. The Kaseya R&D Team is currently 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. identified Apr 10, 2026, 12:47 PM UTC

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

3. monitoring Apr 10, 2026, 03:28 PM UTC

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

4. resolved Apr 10, 2026, 06:21 PM UTC

   This incident has been resolved.

5. postmortem Apr 16, 2026, 08:10 PM UTC

   **DBMA/EBDR - Device failing to register – 2026-04-09** **Summary:** Between 2026-04-09 11:00 AM UTC and 2026-04-10 12:30 PM UTC, Some partners experienced an issue where a subset of Datto Backup for Microsoft Azure and Datto Endpoint Backup with DR devices experienced registration failures. ‌ **Root Cause:** The issue was caused by a release configuration error in which a required system image was not properly marked for production use. As a result, the platform was unable to successfully create operating system disks when provisioning new virtual machines. ‌ **Incident Timeline:** * Identified: 2026-04-09 11:00 AM UTC * Public Notification: 2026-04-09 06:00 PM UTC * Resolved: 2026-04-10 12:30 PM UTC ‌ **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps: * To strengthen reliability going forward, we are introducing additional pre‑release validation steps * Enhancing real‑time monitoring and alerting around provisioning success * Conducting targeted training to improve rapid diagnosis and resolution of similar issues.

Read the full incident report →

Started Apr 08, 2026, 02:12 PM UTC· resolved May 14, 2026, 07:50 PM UTC

1. investigating Apr 01, 2026, 03:45 PM UTC

   We are aware of a problem where Datto Workplace users are reporting elevated latency impacting multiple projects within the U.S. region. The Kaseya R&D Team is currently 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 Apr 02, 2026, 01:02 PM UTC

   We are continuing to investigate this issue.

3. identified Apr 03, 2026, 01:32 PM UTC

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

4. identified Apr 03, 2026, 05:06 PM UTC

   We have identified the root cause of the slow file downloads impacting large projects. The issue is isolated to the server side and does not impact data integrity. A corrective solution is currently under evaluation, and we anticipate providing an updated status early next week.

5. identified Apr 08, 2026, 02:12 PM UTC

   Our engineering team has provided a temporary solution to mitigate the latency issue affecting Datto Workplace. If you wish to implement this workaround, please contact our Technical Support team for assistance with its application.

6. identified Apr 10, 2026, 02:58 PM UTC

   The Kaseya R&D team continues to actively work toward resolving this issue. Please note that any latency impact is limited to VFS/V10 agents.

7. identified Apr 15, 2026, 05:38 PM UTC

   Our engineering team is continuing to investigate a permanent resolution.

8. identified Apr 23, 2026, 08:28 PM UTC

   Our engineering team is actively working on a permanent resolution. We’ll provide updates as progress continues.

9. resolved May 14, 2026, 07:50 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 07, 2026, 06:16 PM UTC· resolved Apr 09, 2026, 06:48 PM UTC

1. identified Apr 07, 2026, 06:16 PM UTC

   We are aware of a problem where BCDR users may experience intermittent performance degradation when accessing a device’s remote web interface. Please be advised that this behavior is transient in nature and is typically resolved by retrying the operation. 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 Apr 08, 2026, 07:07 PM UTC

   The Kaseya R&D team has identified a fix and is currently estimating deployment by the end of this week.

3. monitoring Apr 09, 2026, 03:06 PM UTC

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

4. resolved Apr 09, 2026, 06:48 PM UTC

   This incident has been resolved.

5. postmortem Apr 16, 2026, 07:49 PM UTC

   **BCDR - RLY Connections slow or failing - 2026-04-07** **Summary:** Between 2026-04-07 04:37 PM UTC and 2026-04-09 07:48 PM UTC, Some customers experienced intermittent performance degradation when accessing a device’s remote web interface. **Root Cause:** The incident was caused by a backend database table growing without limits alongside an inefficient background query that scanned the entire dataset. Over time, this placed a sustained load on the database. When a brief infrastructure disruption reduced capacity, the system could not recover quickly enough, leading to cascading database failures.` ` ‌ **Incident Timeline:** Add any major milestones we should disclose publicly * Identified: 2026-04-07 04:37 PM UTC * Public Notification to the Status Page: 2026-04-08 06:16 PM UTC * Resolved: 2026-04-09 07:48 PM UTC **Preventative Measures:** ` ` To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps: * To prevent a recurrence, we removed outdated and unnecessary historical records from the affected database, significantly reducing its size. * Implemented automatic data expiration for new records, ensuring the table remains within healthy bounds and does not grow unchecked in the future.

Read the full incident report →

Started Apr 06, 2026, 03:48 PM UTC· resolved Apr 06, 2026, 05:32 PM UTC

1. identified Apr 06, 2026, 03:48 PM UTC

   We are aware of a problem where job execution is delayed on the Concord & Vidal platforms. The Kaseya R&D Team have identified the issue and are working on implementing a fix. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Apr 06, 2026, 04:06 PM UTC

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

3. resolved Apr 06, 2026, 05:32 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 02, 2026, 06:25 PM UTC· resolved Apr 03, 2026, 12:27 PM UTC

1. investigating Apr 02, 2026, 06:25 PM UTC

   We are aware of a problem where the Datto RMM agent cannot be installed due to Certificate errors. 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 Apr 02, 2026, 09:09 PM UTC

   We are continuing to investigate this issue.

3. monitoring Apr 03, 2026, 11:43 AM UTC

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

4. resolved Apr 03, 2026, 12:27 PM UTC

   This incident has been resolved.

5. postmortem May 08, 2026, 02:09 PM UTC

   ## Summary Between **2026-04-02 10:30 UTC** and **2026-04-02 23:28 UTC**, **Datto RMM** customers experienced failures when attempting to download and install the Datto RMM Agent. Affected users received a Windows security warning indicating an issue with the installer’s digital certificate, and installation was blocked because the code-signing certificate had been revoked. Devices with existing agents were not impacted; only new agent deployments were affected during this period. ## Root Cause The installer’s code-signing certificate had been revoked by the certificate authority, causing Windows security checks to reject the installer and preventing successful agent installation. ## Incident Timeline * **Identified:** 2026-04-02 10:30 UTC * **Public Notification:** 2026-04-02 shortly after detection * **Resolved:** 2026-04-02 23:28 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:** * Implement automated synthetic monitoring to continuously validate the agent installer download and installation process. * Include active checks for certificate validity and revocation status. * Configure these tests to generate immediate alerts upon failure. **Enhancements to Incident Management and Response:** * Establish a dedicated on-call engineering rotation to ensure rapid response when alerts are triggered. * Reduce the time between issue detection and remediation.

Read the full incident report →

Started Apr 01, 2026, 04:53 PM UTC· resolved Apr 03, 2026, 01:24 PM UTC

1. identified Apr 01, 2026, 04:53 PM UTC

   We are aware of a low-frequency issue where certain legitimate files may be unexpectedly quarantined by a behavioral detection component. What’s happening In rare cases, a behavioral detection module may briefly activate during endpoint startup before policy settings are fully applied. During this short window, files that would normally be allowed may be flagged and quarantined. Customer impact Low probability, but non-zero Quarantined files may not generate alerts in the console Files cannot currently be restored directly from the portal What we’re doing Implementing a fix to ensure this component does not activate during startup Rolling out updates in a controlled manner Actively monitoring to ensure the issue is fully resolved What you should do If you believe this has impacted your environment: Contact Support Our team can assist with restoring files from quarantine !!! Important !!! Do not remove AV licenses from affected devices, as this may result in permanent deletion of quarantined files. Next update We will share progress as rollout completes and the fix is fully deployed.

2. identified Apr 02, 2026, 03:03 PM UTC

   A fix has been developed and this will be released tonight, after 12am(EST) and applied during your next set maintenance window.

3. resolved Apr 03, 2026, 01:24 PM UTC

   A fix was deployed 4/2/26 after 11pm and will install to agents during the next set maintenance window.

4. postmortem May 12, 2026, 03:07 PM UTC

   **Summary** Between **February 26, 2026 and April 3rd, 2026**, a subset of Datto AV customers experienced unexpected file quarantines. In these cases, Datto AV incorrectly identified certain legitimate files as threats and quarantined them. **Root Cause** The issue was caused by a Datto AV update released on **February 26, 2026**. This update did not deploy the required application exclusion file to systems where Datto AV had originally been deployed through Datto RMM **prior to June 2025**.` ` As a result, impacted systems lacked the necessary exclusions and misidentified certain files as malicious, leading to unintended quarantines. A corrective update was released on **April 3rd, 2026**, which deployed the missing exclusions and resolved the issue. **Incident Timeline** * **Identified:** March 05, 2026 * **Resolved:** March 20, 2026

Read the full incident report →

Started Mar 30, 2026, 07:42 PM UTC· resolved Mar 30, 2026, 08:20 PM UTC

1. investigating Mar 30, 2026, 07:42 PM UTC

   We are aware of a problem where Datto RMM filters on the Vidal platform are failing to load with an "Out of sort memory" error message. The Kaseya R&D Team is investigating the issue. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Mar 30, 2026, 07:51 PM UTC

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

3. resolved Mar 30, 2026, 08:20 PM UTC

   This incident has been resolved.

4. postmortem Jun 03, 2026, 02:26 PM UTC

   **Summary** Between 2026-03-30 11:17 UTC and 2026-03-30 19:45 UTC, Datto RMM partners on the Vidal platform \(US EAST region\) experienced intermittent errors when attempting to load the results of certain Device Filters. Users were presented with the message _"Device Filter results were not able to be returned. If this problem persists, please contact support."_ instead. **Scope** The issue was confirmed to only impact Device Filters that returned a large number of devices as their result. No other functionalities related to remotely monitoring and managing devices through the Web UI or with remote control tools were impacted. **Root Cause** The issue was identified to be caused by a routine database engine upgrade that caused high sort buffer utilization when performing sorting operations during Filter Result computation. This resulted in the database exhausting the available sort buffer memory and thus failing computation under certain circumstances, showing the user the message _"Device Filter results were not able to be returned.”_ The R&D team upgraded the sort buffer size on the platform which resolved the errors. Due to the intermittent nature of the issue and the limited scope of impact \(~2.79% of partners\), escalation to the R&D team occurred approximately 8 hours after the initial report. Once escalated, R&D quickly identified, confirmed, and resolved the issue within 20 minutes. **Incident Timeline** * **First report to Kaseya Support:** 2026-03-30 11:17 UTC * **Suspected Service Issue Referred to R&D:** 2026-03-30 19:28 UTC * **Service Issue Confirmed and Resolved / Public Notification Issued:** 2026-03-30 19:45 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**: We will implement automated alerting for database sort buffer errors, with notifications routed to a dedicated channel monitored by our development and QA teams around the clock via an on-call rotation. * **Enhancements to Incident Management and Response:** We are reviewing and improving our internal escalation process to reduce the time between initial detection and engineering engagement, targeting a significantly faster response for suspected service issues. * **Enhancements to Release Management Practices:** We will expand our scale testing strategy to include scenarios involving large Device Filter selections, ensuring that this class of operation is validated before future infrastructure changes are applied.

Read the full incident report →

Started Mar 26, 2026, 07:26 PM UTC· resolved Apr 08, 2026, 07:27 PM UTC

1. identified Mar 26, 2026, 07:26 PM UTC

   We are aware of a problem where BCDR assets paired to server1405 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 Mar 31, 2026, 04:58 PM UTC

   The R&D team continues to actively work toward a resolution for this issue. Additional information will be communicated as it becomes available.

3. identified Apr 08, 2026, 07:09 PM UTC

   Efforts to address the underlying issue remain in progress. Additional updates will be provided as they become available.

4. resolved Apr 08, 2026, 07:27 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 26, 2026, 03:21 PM UTC· resolved Mar 26, 2026, 05:59 PM UTC

1. investigating Mar 26, 2026, 03:21 PM UTC

   We are aware of a problem where Creating or saving Monitoring Policies fails with "could not execute statement" error. 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. monitoring Mar 26, 2026, 03:39 PM UTC

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

3. resolved Mar 26, 2026, 05:59 PM UTC

   This incident has been resolved.

4. postmortem May 26, 2026, 01:20 PM UTC

   **Summary:** Between 2026-03-26 14:22 UTC and 2026-03-26 15:30 UTC, Datto RMM partners in the Concord platform \(US East\) were intermittently unable to create new Monitoring Policies or edit existing ones, receiving an error when attempting to save their work. **Scope:** The impact was limited to creating and updating Monitoring Policies in the Web UI on the Concord platform \(US East region\). All other functionalities in the Web UI, as well as Managed Device connections and interactions, were unaffected. **Root Cause:** A temporary spike in internal database activity caused write operation timeouts and subsequent retries that degraded performance for policy create/update requests. The service automatically recovered when database activity returned to normal levels. **Incident Timeline:** * **First report to Kaseya Support:** 2026-03-26 13:22 UTC * **Engineering Investigation Began:** 2026-03-26 14:10 UTC * **Resolved:** 2026-03-26 14:30 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:** The R&D team is continuing the collaboration with AWS to better understand and mitigate database activity spikes, including analysis of query throughput, transaction contention, and connection utilization patterns in order to reduce the risk of a repeated occurrence. * **Enhancements to Observability and Diagnostics:** The R&D team is expanding log analysis and telemetry efforts to identify recurring patterns in database engine behavior, helping to reduce the time needed to detect and respond to early indicators of similar issues in the future.

Read the full incident report →

Started Mar 25, 2026, 02:43 PM UTC· resolved Mar 27, 2026, 02:17 PM UTC

1. identified Mar 25, 2026, 02:43 PM UTC

   We are aware of a problem where BCDR users paired to server5856 in the US-East region 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 Mar 27, 2026, 01:18 PM UTC

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

3. resolved Mar 27, 2026, 02:17 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 25, 2026, 01:30 PM UTC· resolved Mar 25, 2026, 01:30 PM UTC

1. resolved Mar 25, 2026, 03:04 PM UTC

   Starting at 9:30 AM Eastern time, ConnectBooster Live Portals were inaccessible. Users could not log in and customers were not able to make payments. The Kaseya R&D Team resolved the issue at 10:10 AM Eastern time. All users should now be able to access their Live portals as expected. Subscribe to this Kaseya Status Page to be notified when an RCA is posted.

2. postmortem Mar 27, 2026, 05:22 PM UTC

   **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.

Read the full incident report →

Started Mar 24, 2026, 11:44 PM UTC· resolved Mar 25, 2026, 02:41 PM UTC

1. investigating Mar 24, 2026, 11:44 PM UTC

   We are aware of an issue where Datto Endpoint Backup for PC users paired with Cloud Siris 'use1-dtc-server-143' may experience degraded performance, which can result in slower-than-average backup and restore speeds. 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. resolved Mar 25, 2026, 02:41 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 24, 2026, 08:11 PM UTC· resolved May 14, 2026, 07:41 PM UTC

1. investigating Mar 24, 2026, 08:11 PM UTC

   We have identified an issue introduced in the latest device software release related to agents running 32 bit versions of Windows Server 2003 and Windows XP where screenshot verification and local virtualization fails to start. We are currently investigating the issue to determine the cause and potential fix. In the meantime, we have verified that cloud virtualizations are still functional for any DR scenarios. We will provide more information as it becomes available.

2. identified Mar 25, 2026, 04:24 PM UTC

   Our R&D team has identified the underlying issue and is actively working toward a targeted resolution. The deployment window is projected to commence upon completion of the current major device release. In the interim, please utilize cloud‑based virtualization services to ensure continued operational continuity in the event of a Disaster Recovery scenario. Please note: This issue is currently impacting only a limited subset of the Datto Windows Agent fleet.

3. resolved May 14, 2026, 07:41 PM UTC

   We’re pleased to inform you that our Engineering team has released a fix that should resolve the problem where BCDR Agents operating on 32-bit versions of Windows Server 2003 and Windows XP are experiencing failures with screenshot verification, and local virtualization processes are not successfully initializing. If the problem is still occurring, please make sure your device is fully up to date on the latest OS version. Please note, we have started to roll out the update to devices on 05/11/2026 and the release will complete for all devices by 05/28/2026. Thank you for your patience and understanding. We remain committed to delivering exceptional service and continuous improvement. Best regards,

Read the full incident report →

Started Mar 24, 2026, 02:24 PM UTC· resolved Mar 24, 2026, 05:45 PM UTC

1. identified Mar 24, 2026, 02:24 PM UTC

   We are aware of a problem where users paired to server 'gbe2-dtc-server-157' in the UK 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. monitoring Mar 24, 2026, 04:04 PM UTC

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

3. resolved Mar 24, 2026, 05:45 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 23, 2026, 04:39 PM UTC· resolved Mar 23, 2026, 07:30 PM UTC

1. investigating Mar 23, 2026, 04:39 PM UTC

   We are aware of a problem where some device filters on Merlot and Pinotage are failing to load with an error pop-up saying: "Device Filter results were not able to be returned." 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. monitoring Mar 23, 2026, 06:31 PM UTC

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

3. resolved Mar 23, 2026, 07:30 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 20, 2026, 11:39 AM UTC· resolved Mar 23, 2026, 02:10 PM UTC

1. investigating Mar 20, 2026, 11:39 AM UTC

   We are currently investigating an issue affecting some customers hosted on pods 'use1-saas-p7' and 'use1-saas-p8', where performance degradation has been observed affecting all backups. The Kaseya R&D team has identified the root cause and is actively working on a resolution. Further updates will be provided as progress is made.

2. identified Mar 20, 2026, 12:05 PM UTC

   The R&D team identified the root cause of the problem and they are working on resolving the issue.

3. identified Mar 20, 2026, 02:16 PM UTC

   Backups are processing normally again on pod 'use1-saas-p7' and backup success rate metrics are improving. The R&D team has identified another issue still affecting backups on pod 'use1-saas-p8' and they are actively working to resolve it.

4. identified Mar 20, 2026, 05:37 PM UTC

   Our R&D team is continuing to implement changes to address the backup issues affecting customers hosted on pod 'use1-saas-p8' Backups continue to process normally on pod 'use1-saas-p7' and backup success rates should fully recover in the next couple of hours.

5. identified Mar 20, 2026, 05:53 PM UTC

   Our R&D team has implemented a fix to address the backup issues affecting pod 'use1-saas-p8' and backups have started to process normally again.

6. monitoring Mar 20, 2026, 07:09 PM UTC

   Backups success rates for pod 'use1-saas-p7' have returned to normal levels and remain stable. Customer backups on pod 'use1-saas-p8' are continuing to process normally and our R&D team is monitoring recovery as backup success rates improve.

7. monitoring Mar 22, 2026, 07:20 PM UTC

   Backups success rates for both pods 'use1-saas-p7' and 'use1-saas-p8' have returned to normal levels. Our R&D team is continuing to monitor for any other issues.

8. resolved Mar 23, 2026, 02:10 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 20, 2026, 10:48 AM UTC· resolved Mar 20, 2026, 01:54 PM UTC

1. investigating Mar 20, 2026, 10:48 AM UTC

   We are aware of a problem where Agent-based alerts are not being raised on the platform for Datto RMM on the Merlot platform The Kaseya R&D Team are aware of the issue and are investigating the root cause. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Mar 20, 2026, 12:21 PM UTC

   The R&D team identified the cause of the issue and implemented a fix. New alerts are now creating on the platform in real time, and previous alerts impacted by this issue are being processed and will be raised in the accounts within the next 2 hours.

3. resolved Mar 20, 2026, 01:54 PM UTC

   This incident has been resolved.

4. postmortem Apr 30, 2026, 07:53 AM UTC

   **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.

Read the full incident report →

Started Mar 19, 2026, 05:00 AM UTC· resolved Mar 19, 2026, 05:00 AM UTC

1. resolved Apr 08, 2026, 06:41 PM UTC

   On March 19, 2026, at approximately 1:00 AM EDT, Datto Workplace and Datto File Protection partners in the AU5 region experienced a brief and transient network disruption that temporarily impacted application access and file synchronization. A resolution was formally established on March 19, 2026, at 11:51 a.m. EDT. We greatly appreciate your understanding and thank you for your partnership.

Read the full incident report →

Started Mar 18, 2026, 10:49 AM UTC· resolved Mar 19, 2026, 01:12 PM UTC

1. identified Mar 18, 2026, 10:49 AM UTC

   We are currently investigating an issue affecting some customers hosted on pod use1-saas-p5, where backup performance degradation has been observed for certain SharePoint services. The Kaseya R&D team has identified the root cause and is actively working on a resolution. Further updates will be provided as progress is made.

2. monitoring Mar 18, 2026, 12:30 PM UTC

   We are seeing continued improvement in backup performance on pod use1-saas-p5. The R&D team will continue monitoring the environment until full recovery is confirmed.

3. monitoring Mar 18, 2026, 02:07 PM UTC

   Backups are processing normally and backup success rates continue to improve. Our R&D team is continuing to monitor.

4. resolved Mar 19, 2026, 01:12 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 16, 2026, 03:16 PM UTC· resolved Mar 16, 2026, 04:30 PM UTC

1. investigating Mar 16, 2026, 03:16 PM UTC

   We are aware of a problem where Endpoint Backup v2 registration, backup, restore requests are not initiating successfully. The Kaseya R&D Team is currently 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. resolved Mar 16, 2026, 04:30 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 16, 2026, 11:08 AM UTC· resolved Mar 16, 2026, 08:08 PM UTC

1. identified Mar 16, 2026, 11:08 AM UTC

   We are aware of an issue affecting backup performance for some customers hosted on pod use1-saas-p9. Our R&D team is actively working to restore the service to full capacity. In the meantime, backup processing may be delayed, but the team is working to ensure daily backups are completed within the 24-hour window. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Mar 16, 2026, 11:47 AM UTC

   Operations have been restored by the R&D team. We are continuing to monitor the service to ensure full recovery.

3. resolved Mar 16, 2026, 08:08 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 11, 2026, 01:33 PM UTC· resolved Mar 12, 2026, 05:09 PM UTC

1. identified Mar 11, 2026, 01:33 PM UTC

   We are aware of a problem where Datto Networking DNA devices' dynamic DNS addresses have been inadvertently configured with an incorrect private IP address. 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 Mar 11, 2026, 02:35 PM UTC

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

3. resolved Mar 12, 2026, 05:09 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 10, 2026, 03:29 PM UTC· resolved Jul 15, 2026, 03:02 PM UTC

1. identified Mar 10, 2026, 03:29 PM UTC

   We are aware of a problem where some customers hosted on pod 'des1-saas-p1' are experiencing backup performance degradation for some SharePoint services. The Kaseya R&D Team has identified the issue and are actively working to resolve it. In the meantime, the R&D team has temporarily decreased the daily backup frequency on pod 'des1-saas-p1' from 3x per day to 2x per day to help maintain high backup success rates amidst ongoing spikes in Microsoft throttling. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Mar 10, 2026, 07:28 PM UTC

   The Kaseya R&D team has implemented additional changes to help address the issue and are monitoring the results closely.

3. identified Mar 11, 2026, 03:08 PM UTC

   After the changes implemented yesterday, the Kaseya R&D team is working to deploy additional improvements to further address the degraded backup performance affecting some customers hosted on pod 'des1-saas-p1'.

4. identified Mar 11, 2026, 04:52 PM UTC

   Issues affecting Teams backup performance have been identified and our R&D team is continuing to address the underlying problem affecting SharePoint/Teams backup performance for some customers hosted on the pod.

5. identified Mar 11, 2026, 08:27 PM UTC

   Recent changes made to improve SharePoint and Teams backup performance did not produce the expected results. Our R&D team will be implementing additional mitigation measures over the next 24 hours to further stabilize SharePoint and Teams backups for customers on the pod. As part of this work, we will be temporarily reducing backup frequency for customers from 2x backups per day to 1x backups per day. These adjustments are intended to improve overall system reliability while long‑term enhancements continue.

6. identified Mar 12, 2026, 11:26 AM UTC

   The R&D team has successfully restored pod stability, and backups are now processing in real time. They are working to resume the schedule of two backups per day, beginning with the next backup window. Additional capacity is also being added to maintain continued pod stability, and to enable increasing the backup cadence to 3 backups per day in the near future.

7. identified Mar 12, 2026, 08:01 PM UTC

   Backup frequency on the pod was increased to 2 backups per day again and our R&D team is monitoring closely as backup success rates continue to improve.

8. identified Mar 13, 2026, 04:03 PM UTC

   Backups continue to process normally at 2x backups per day and success rates remain stable. Our R&D team will continue to monitor backup performance on the pod closely over the weekend as they prepare to increase backup frequency to 3x backups per day early next week.

9. identified Mar 16, 2026, 06:35 PM UTC

   Backups remain stable at 2x backups per day and our R&D team is continuing to monitor closely. The backup frequency will be increased to 3x backups per day when it is safe and reliable for all customers hosted on the pod.

10. monitoring Mar 18, 2026, 07:32 PM UTC

    Backup frequency on this pod is still set to 2x backups per day to maintain high backup success rates while the R&D team continues to develop and test improvements to address the issue. The backup frequency will be increased to 3x backups per day when it is safe and reliable for all customers hosted on the pod. Backup success rates remain stable and the R&D team is continuing to monitor.

11. monitoring Mar 25, 2026, 07:55 PM UTC

    Daily backup cadence on pod ‘des1‑saas‑p1’ remains temporarily set to 2x backups per day to maintain high backup success rates amidst ongoing spikes in Microsoft throttling. Our R&D teams are actively developing and testing improvements to address the issue, with a targeted release in Q2 2026. We will restore the 3x daily backup cadence when it is safe and reliable for all customers on the pod.

12. monitoring Apr 17, 2026, 02:03 PM UTC

    We are aware of additional reports of backup performance degradation affecting SharePoint services on pod 'des1-saas-p1'. Our R&D team has implemented changes to address the issue and are monitoring.

13. monitoring Apr 20, 2026, 12:47 PM UTC

    After monitoring over the weekend, all services are backing up normally at 2x backup per day again. Our R&D teams are continuing to develop and test improvements to address the issue, with a targeted release in Q2 2026. We will restore the 3x daily backup cadence when it is safe and reliable for all customers on the pod.

14. monitoring May 14, 2026, 07:24 PM UTC

    The backup cadence on pod 'des1‑saas‑p1' remains temporarily set to 2x daily backups to maintain high success rates amid Microsoft throttling. R&D is continuing to develop improvements, targeted for release Q2 2026. The 3x daily backup cadence will be restored once it is stable and reliable for all customers.

15. monitoring Jun 15, 2026, 03:27 PM UTC

    Our R&D team has increased the daily backup cadence on pod 'des1-saas-p1' from 2x daily backups to 3x daily backups and they are actively monitoring backup performance of all services on the pod.

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

    Backup cadence on pod 'des1-saas-p1' remains at the normal 3x daily backups and our R&D team has deployed additional improvements to further address the issue. They are continuing to closely monitor backup performance of all services on the pod.

17. resolved Jul 15, 2026, 03:02 PM UTC

    This incident has been resolved.

Read the full incident report →

Started Mar 09, 2026, 07:17 PM UTC· resolved Mar 20, 2026, 01:13 PM UTC

1. identified Mar 09, 2026, 07:17 PM UTC

   We are aware of a problem where Datto BCDR users in the Germany region associated with server3818 may experience reduced 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. monitoring Mar 16, 2026, 05:13 PM UTC

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

3. resolved Mar 20, 2026, 01:13 PM UTC

   This incident has been resolved.

Read the full incident report →