Datto Outage History

Started Jul 30, 2026, 03:11 PM UTC· resolved Aug 05, 2026, 07:46 PM UTC

1. investigating Jul 30, 2026, 03:11 PM UTC

   We are aware of a problem where some customers hosted on pod 'gbe2-saas-p0' are experiencing backup performance degradation for some Teams/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 Jul 30, 2026, 03:33 PM UTC

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

3. monitoring Jul 30, 2026, 06:33 PM UTC

   Our R&D team has implemented a fix on pod 'gbe2-saas-p0' to address the backup performance degradation affecting some Teams/SharePoint services and we are closely monitoring the results.

4. monitoring Jul 31, 2026, 01:55 PM UTC

   Our R&D team has implemented additional changes to further address the issue and they are continuing to closely monitor backup performance on pod 'gbe2-saas-p0' as backup success rate metrics improve.

Read the full incident report →

Started Jul 30, 2026, 01:44 PM UTC· resolved Jul 30, 2026, 08:04 PM UTC

1. investigating Jul 30, 2026, 01:44 PM UTC

   We are aware of a problem where SaaS Protection customers hosted on node 'des1-bfyii-2985' are unable to access their accounts and are experiencing a disruption to their 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. identified Jul 30, 2026, 03:45 PM UTC

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

3. monitoring Jul 30, 2026, 04:26 PM UTC

   Our R&D team has implemented a fix to restore account access and have confirmed backups are running. We are monitoring for any other issues.

4. resolved Jul 30, 2026, 08:04 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 29, 2026, 10:55 AM UTC· resolved Jul 29, 2026, 08:15 PM UTC

1. identified Jul 29, 2026, 10:55 AM UTC

   We are aware of an issue where Datto SaaS Protection customers hosted on pod gbe2-saas-p0 are experiencing a complete service disruption. The Kaseya Engineering Team has identified the issue and is actively working to restore service as quickly as possible. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jul 29, 2026, 10:56 AM UTC

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

3. identified Jul 29, 2026, 12:23 PM UTC

   Our R&D team has applied a fix to address the issue and they are currently verifying restoration of all services on pod 'gbe2-saas-p0'.

4. identified Jul 29, 2026, 01:45 PM UTC

   Our R&D team is continuing to address the issue and fully restore SaaS Protection services on pod 'gbe2-saas-p0'.

5. identified Jul 29, 2026, 03:02 PM UTC

   Our R&D team has confirmed that backups are currently processing normally on pod 'gbe2-saas-p0' however they are continuing to address an issue affecting customer account access.

6. identified Jul 29, 2026, 04:38 PM UTC

   Our R&D team is continuing to address the account access issues still affecting some SaaS Protection customers hosted on pod 'gbe2-saas-p0' as well as monitoring backup performance.

7. monitoring Jul 29, 2026, 05:12 PM UTC

   Our R&D team has implemented additional changes to address the intermittent account access issues that were still affecting some customers hosted on pod 'gbe2-saas-p0' and backups for all services are continuing to process. We will be monitoring the pod closely for any other issues.

8. resolved Jul 29, 2026, 08:15 PM UTC

   Backups continue to process and all customer accounts hosted on pod 'gbe2-saas-p0' are accessible and functioning normally. This incident is resolved.

Read the full incident report →

Started Jul 28, 2026, 06:01 PM UTC· resolved Jul 29, 2026, 07:04 AM UTC

1. investigating Jul 28, 2026, 06:01 PM UTC

   We are aware of a problem where tickets are not getting created from inbound emails. The Kaseya Engineering Team is investigating the issue. Should you need 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/

2. monitoring Jul 28, 2026, 06:06 PM UTC

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

3. resolved Jul 29, 2026, 07:04 AM UTC

   This incident has been resolved. All inbound emails that occurred during the incident timeframe have been successfully reprocessed.

4. postmortem Aug 12, 2026, 01:29 PM 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.

Read the full incident report →

Started Jul 28, 2026, 12:52 PM UTC· resolved Jul 29, 2026, 11:59 PM UTC

1. investigating Jul 28, 2026, 12:52 PM UTC

   We are aware of a problem where Endpoint Backup v2 assets in UniView may incorrectly indicate backup failures despite successful backup completion, which can trigger unnecessary email notifications. 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 Jul 28, 2026, 06:04 PM UTC

   We are continuing to investigate this issue.

3. monitoring Jul 28, 2026, 11:59 PM UTC

   Our R&D team has implemented a fix, and we're seeing improved performance across the affected systems. We're continuing to monitor the environment to ensure the improvements are sustained.

4. resolved Jul 29, 2026, 11:59 PM UTC

   This incident has been resolved. 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.

5. postmortem Sep 02, 2026, 01:53 PM 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.

Read the full incident report →

Started Jul 28, 2026, 12:47 PM UTC· resolved Aug 05, 2026, 07:46 PM UTC

1. identified Jul 28, 2026, 12:47 PM UTC

   We are aware of a problem where some Datto SaaS Protection customers hosted on pod 'gbe2-saas-p2' may be experiencing backup performance degradation affecting some SharePoint/Teams services. The Kaseya Engineering 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. identified Jul 28, 2026, 06:02 PM UTC

   Our R&D team has implemented changes on pod 'gbe2-saas-p2' to mitigate the backup performance issues affecting some SharePoint and Teams services.

3. monitoring Jul 28, 2026, 08:07 PM UTC

   Backup success rates for SharePoint/Teams services on pod 'gbe2-saas-p2' are improving after the changes made on the pod earlier today. Our R&D team is continuing to monitor.

4. monitoring Jul 29, 2026, 03:20 PM UTC

   Backup success rates for SharePoint/Teams services on pod 'gbe2-saas-p2' have returned to normal levels. Our R&D team is continuing to monitor.

5. monitoring Jul 30, 2026, 03:48 PM UTC

   Backup success rates for SharePoint/Teams services on pod 'gbe2-saas-p2' are currently stable at normal levels. Our R&D team is making additional adjustments to the configuration on the pod to further address the issue and will continue to monitor.

6. monitoring Jul 31, 2026, 01:58 PM UTC

   Backup success rate metrics for SharePoint/Teams services on pod 'gbe2-saas-p2' remain stable at normal levels. Our R&D team is continuing to monitor.

Read the full incident report →

Started Jul 27, 2026, 05:35 PM UTC· resolved Jul 27, 2026, 08:00 PM UTC

1. investigating Jul 27, 2026, 05:35 PM UTC

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

2. identified Jul 27, 2026, 06:16 PM UTC

   The issue has been identified and the R&D team is actively working to resolve it.

3. monitoring Jul 27, 2026, 06:59 PM UTC

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

4. resolved Jul 27, 2026, 08:00 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 24, 2026, 01:27 PM UTC· resolved Jul 24, 2026, 09:23 PM UTC

1. identified Jul 24, 2026, 01:27 PM UTC

   We are aware of a problem where customers hosted on EMEA/APAC app servers may see intermediate service disruption, getting 500 - internal server error. The Kaseya Engineering Team has identified the issue and working towards a fix. Should you need 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/

2. identified Jul 24, 2026, 03:46 PM UTC

   The Kaseya Engineering Team has developed a fix that will address this issue. The fix will be deployed after hours to our EMEA and APAC App Servers on the following schedule: 17:00 UTC APAC 20:00 UTC EMEA Those that are online during this change will need to login again as they will be kicked out the system. 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/

3. monitoring Jul 24, 2026, 08:25 PM UTC

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

4. resolved Jul 24, 2026, 09:23 PM UTC

   This incident has been resolved.

5. postmortem Aug 12, 2026, 07:57 PM 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.

Read the full incident report →

Started Jul 24, 2026, 08:47 AM UTC· resolved Jul 24, 2026, 10:29 AM UTC

1. investigating Jul 24, 2026, 08:47 AM UTC

   We are aware of an issue where customers are encountering 500 errors while accessing Backup products within the Datto Partner Portal (DPP). 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 Jul 24, 2026, 10:06 AM UTC

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

3. resolved Jul 24, 2026, 10:29 AM UTC

   This incident has been resolved.

4. postmortem Aug 05, 2026, 05:55 PM UTC

   **Datto Partner Portal - Intermittent HTTP 500 errors encountered when accessing the Portal and Recovery Launchpad – 2026-07-24** **Summary:** Between **2026-07-24 03:00 AM UTC** and **2026-07-24 11:29 AM UTC**, Datto BCDR customers experienced login issues when attempting to access the Datto Partner Portal and Recovery Launchpad. **Root Cause:** During the onboarding of a firewall environment into centralized management, an unexpected configuration synchronization event created an inconsistent configuration state. This resulted in the removal of critical routing information, loss of some VPN authentication settings, and the creation of duplicate configuration entries, causing an internet outage, delaying VPN recovery for affected sites, and preventing a standard rollback. Manual remediation and restoration to the last known stable configuration were required to fully recover services. **Incident Timeline:** * Identified: 2026-07-24 03:00 AM UTC * Public Notification: 2026-07-24 08:47 AM UTC * Resolved: 2026-07-24 11:29 AM UTC **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * Implement VPN traffic baseline monitoring and alerting to detect abnormal activity and enable faster issue identification. * Define a rollback SOP with clear decision criteria and timelines for outages caused by software defects during planned maintenance.

Read the full incident report →

Started Jul 23, 2026, 03:15 PM UTC· resolved Jul 23, 2026, 09:19 PM UTC

1. investigating Jul 23, 2026, 03:15 PM UTC

   We are aware of a problem where the KaseyaOne Portal is not accessible. The Kaseya R&D Team is investigating the issue. Should you have any questions or require assistance, please contact our support team at https://helpdesk.kaseya.com/hc/en-gb#/phone Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/ As a note; To ensure business continuity, for Kaseya modules using Require Log In with KaseyaOne, users must authenticate using their KaseyaOne Unified Login credentials. Users added as exceptions can still log in using local module-specific credentials. Details are available in this Knowledge Base article: https://help.one.kaseya.com/help/Content/1_Configuration/enable-require-login-with-K1.htm We recommend adding a small set of users to the override list to maintain access in the event of a future disruption or maintenance, helping ensure continuous business operations

2. identified Jul 23, 2026, 03:49 PM UTC

   We have verified that the KaseyaOne Portal is being impacted by the Microsoft Azure Outage. Please follow their Status Post as well for updates: https://azure.status.microsoft/en-us/status

3. identified Jul 23, 2026, 05:06 PM UTC

   Kaseya R&D are continuing to work closely with Microsoft Azure to resolve this issue affecting the KaseyaOne Portal.

4. identified Jul 23, 2026, 06:26 PM UTC

   We have identified additional Kaseya Products that rely on Microsoft Azure Infrastructure that are affected by this issue. Partners using Datto / Unitrends Backup for Microsoft Azure and Datto / Unitrends Endpoint Backup with Disaster Recovery in the US West region will experience issues with Device Check-In, Device Registration, and Back Up. The Kaseya R&D team are continuing to work with the Microsoft Azure team to resolve this issue and we hope to have updates on a resolution as soon as possible.

5. monitoring Jul 23, 2026, 06:40 PM UTC

   A fix has been implemented by Microsoft Azure and we are monitoring the results. Please refer to the Microsoft Status page here: https://azure.status.microsoft/en-us/status for more details

6. resolved Jul 23, 2026, 09:19 PM UTC

   This incident has been resolved.

7. postmortem Aug 10, 2026, 03:29 PM UTC

   # Summary: Between 2026-07-23 14:44 UTC and 2026-07-23 19:41 UTC, KaseyaOne customers were unable to access the KaseyaOne Portal, and authentication into integrated applications that relied on KaseyaOne SSO was also impacted. # Root Cause: A network connectivity issue affecting the Microsoft Azure West US region caused service disruption for infrastructure supporting KaseyaOne. This resulted in loss of portal accessibility and SSO functionality until Microsoft restored regional connectivity. ## Incident Timeline: * Identified: 2026-07-23 14:45 UTC * Public Notification: 2026-07-23 15:15 UTC * Resolved: 2026-07-23 19:41 UTC # Preventative Measures: To reduce the likelihood and impact of similar incidents in the future, we are making Enhancements to Infrastructure Resiliency. Specifically: * Implementing a multi-region deployment architecture with designated primary and disaster recovery regions. This enhancement will reduce reliance on a single Azure region and improve service availability during regional infrastructure failures.

Read the full incident report →

Started Jul 23, 2026, 01:37 PM UTC· resolved Jul 27, 2026, 02:45 PM UTC

1. identified Jul 23, 2026, 01:37 PM UTC

   We are aware of a problem where web filtering configuration changes are not being successfully applied on the DNA and D200 appliances. 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. identified Jul 24, 2026, 03:49 PM UTC

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

3. monitoring Jul 27, 2026, 12:33 PM UTC

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

4. resolved Jul 27, 2026, 02:45 PM UTC

   This incident has been resolved.

5. postmortem Aug 03, 2026, 03:27 PM UTC

   **Datto Networking- Web filtering policy changes fail to deploy to DNA and D200 appliances – 2026-07-17** **Summary:** Between **2026-07-17 10:37 PM UTC** and **2026-07-27 02:45 PM UTC**, **Datto Networking** customers experienced an issue where web filtering configuration changes were not being successfully applied on the DNA and D200 appliances. **Root Cause:** The issue was traced to an application integration change that resulted in processing errors and prevented certain configuration updates from being applied successfully. An additional issue affecting the application of category-based configuration changes was also identified. Remediation for both issues was developed promptly. **Incident Timeline:** * Identified: **2026-07-17 10:37 PM UTC** * Public Notification: **2026-07-23 02:37 PM UTC** * Resolved: **2026-07-27 02:45 PM UTC** **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * Improve monitoring and alerting effectiveness to accelerate issue identification, streamline triage activities, and support service reliability. * Complete the transition away from legacy infrastructure dependencies to improve platform resilience, reduce operational risk, and prevent similar issues from recurring.

Read the full incident report →

Started Jul 23, 2026, 08:22 AM UTC· resolved Jul 23, 2026, 09:24 AM UTC

1. investigating Jul 23, 2026, 08:22 AM UTC

   We are aware of a problem where partners in our UK03 zone are receiving error messages when navigating the UI. 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 Jul 23, 2026, 08:52 AM UTC

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

3. resolved Jul 23, 2026, 09:24 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 23, 2026, 04:17 AM UTC· resolved Jul 23, 2026, 06:26 AM UTC

1. investigating Jul 23, 2026, 04:17 AM UTC

   We are currently experiencing service disruption in DES1 DC. Our team is working to restore the functionality on the affected instances at this time. We apologize for any inconvenience this may cause. - Kaseya Cloud Operations Team

2. monitoring Jul 23, 2026, 04:29 AM UTC

   Service has been restored. All targets in the DES1 data center are now accessible and fully operational. Apologies for the inconvenience caused. - Kaseya Cloud Operations Team.

3. monitoring Jul 23, 2026, 04:30 AM UTC

   We are continuing to monitor this.

4. resolved Jul 23, 2026, 06:26 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 21, 2026, 06:05 PM UTC· resolved Jul 21, 2026, 06:42 PM UTC

1. investigating Jul 21, 2026, 06:05 PM UTC

   We are aware of a problem where SaaS Protection customers hosted on node 'aue1-bfyii-2319' are unable to access their accounts and are experiencing a disruption to their 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 Jul 21, 2026, 06:29 PM UTC

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

3. resolved Jul 21, 2026, 06:42 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 21, 2026, 08:55 AM UTC· resolved Jul 22, 2026, 11:51 AM UTC

1. investigating Jul 21, 2026, 08:55 AM UTC

   The Kaseya R&D Team is currently investigating reported issues on the Merlot platform with pages across the Datto RMM Web Application loading slowly or failing to load. Device audit attempts have also been observed to be consistently unsuccessful. Thank you for your patience while we are working on identifying and resolving the issue. Please subscribe to this incident to receive notifications when an update is posted.

2. monitoring Jul 21, 2026, 10:06 AM UTC

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

3. investigating Jul 21, 2026, 03:09 PM UTC

   The Kaseya R&D Team is currently investigating additional reports on the Merlot platform where pages and functions across the Datto RMM Web Application may load slowly or fail to load. Thank you for your patience while we are working on identifying and resolving the issue. Please subscribe to this incident to receive notifications when an update is posted.

4. monitoring Jul 21, 2026, 05:14 PM UTC

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

5. resolved Jul 22, 2026, 11:51 AM UTC

   This incident has been resolved.

6. postmortem Jul 28, 2026, 08:20 PM UTC

   **Root Cause Analysis – Datto RMM Merlot Intermittent User Interface Degradation** **Summary** Between **2026-07-21 07:55 UTC** and **2026-07-21 17:00 UTC**, some customers on the Merlot platform experienced intermittent performance degradation within Datto RMM. During this period, users may have encountered slow-loading or failing pages, missing Global Search results, delayed or incomplete device summary information, and intermittent issues accessing certain functionality within the web interface. Service stability was restored following a series of remediation activities targeting the affected messaging and application services. **Root Cause** Our investigation determined that the incident was caused by instability within a core messaging service dependency path used by several Datto RMM components. This instability impacted communication between application services, resulting in elevated backend resource utilization and intermittent failures of customer-facing workflows. The issue was further compounded by the persistence of unhealthy service connections from the recent incident the day prior, which contributed to message processing delays and reduced application responsiveness. Recovery required restarting the affected messaging infrastructure and dependent services, along with infrastructure adjustments to restore normal operation. **Incident Timeline** * Identified: 2026-07-21 07:55 UTC * Public Notification: 2026-07-21 08:55 UTC * Incident Monitoring: 2026-07-21 10:06 UTC * Additional Investigation: 2026-07-21 15:09 UTC * Resolved: 2026-07-21 17:14 UTC **Preventative Measures** To reduce the likelihood and impact of similar incidents in the future, we are taking the following actions: * **Enhancing infrastructure resiliency** by improving service recovery mechanisms so dependent services can recover automatically when messaging infrastructure is restored, reducing the risk of cascading failures across connected services. * **Enhancing monitoring and alerting** by implementing additional monitoring for messaging service health, queue backlog growth, and end-to-end workflow execution so potential issues can be identified and resolved before customer impact occurs. * **Enhancing customer experience monitoring** by introducing workflow-based monitoring and dashboards focused on key customer journeys, allowing earlier identification of degraded user experiences within the platform. * **Enhancing incident management and response** by developing and documenting recovery procedures for messaging-path degradation scenarios, including validation steps to ensure all related services are operating normally before an incident is considered resolved. * **Enhancing post-incident validation** by adding additional dependency-aware validation checks following major recovery activities to confirm the health of interconnected services and reduce the likelihood of follow-on incidents.

Read the full incident report →

Started Jul 20, 2026, 01:00 PM UTC· resolved Jul 20, 2026, 01:00 PM UTC

1. resolved Jul 20, 2026, 02:06 PM UTC

   We are pleased to inform you that the recent service incident experienced by our BCDR partners where users experienced difficulties logging into the Datto Partner Portal has now been successfully resolved. We understand the impact that such problems can have on your business operations, and we sincerely apologize for any inconvenience caused during this time. Our team has been diligently working to identify the root cause of the problem. Our goal is to not only address the immediate concern but also to minimize the risk of similar incidents in the future. By analyzing the underlying factors, we aim to enhance our systems and processes, ensuring a more robust and reliable experience for all our partners. Thank you for your patience and understanding. We remain committed to delivering exceptional service and continuous improvement. Best regards,

2. postmortem Jul 30, 2026, 03:34 PM UTC

   **Datto Partner Portal - Partner Portal Inaccessible– 2026-07-20** **Summary:** Between **2026-07-20 01:00 PM UTC** and **2026-07-20 01:10 PM UTC**, **Datto Partner Portal** customers experienced difficulties logging into the Datto Partner Portal. **Root Cause:** The incident was caused by an infrastructure component that was no longer responding as expected, resulting in the Datto Partner Portal becoming unavailable to users. To restore service, traffic was redirected to a secondary, redundant component in accordance with established recovery procedures. This action successfully restored portal accessibility and normal service operations. **Incident Timeline:** * Identified: 2026-07-20 01:00 PM UTC * Public Notification: 2026-07-20 01:00 PM UTC * Resolved: 2026-07-20 01:10 PM UTC **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * We are updating our resiliency and failover procedures to include additional validation checks that confirm services remain accessible to customers. This enhancement will further strengthen our ability to detect and remediate availability issues.

Read the full incident report →

Started Jul 20, 2026, 12:54 PM UTC· resolved Jul 21, 2026, 10:06 AM UTC

1. investigating Jul 20, 2026, 12:54 PM UTC

   We are currently receiving reports of Merlot agents appearing as offline. We are aware of this and we are investigating.

2. investigating Jul 20, 2026, 03:22 PM UTC

   Investigation efforts are ongoing as our teams continue to work diligently on this issue.

3. monitoring Jul 20, 2026, 04:48 PM UTC

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

4. resolved Jul 21, 2026, 10:06 AM UTC

   This incident has been resolved.

5. postmortem Jul 28, 2026, 07:25 PM UTC

   **Root Cause Analysis – Datto RMM Merlot Devices Appearing Offline** **Summary** Between **2026-07-20 11:39 UTC** and **2026-07-20 15:00 UTC**, Datto RMM partners on the **Merlot** platform experienced device connectivity degradation. During this time, some devices incorrectly appeared offline, partners may have received false offline alerts, and access to affected devices may have been reduced. Our teams detected the issue through internal monitoring and partner reports, investigated the service degradation, and restored stability by increasing capacity across the affected connectivity infrastructure. **Root Cause** The incident was caused by elevated load and resource contention affecting a core device connectivity service. This reduced service responsiveness and caused a large number of agents to disconnect and reconnect. The resulting reconnect activity increased demand on the connectivity infrastructure, causing devices to appear offline within the platform and generating false offline alerts for some partners. **Incident Timeline** * Identified: 2026-07-20 11:39 UTC * Public notification: 2026-07-20 12:54 UTC * Resolved: 2026-07-20 16:48 UTC **Preventative Measures** To reduce the likelihood and impact of similar incidents in the future, we are taking the following actions: * **Enhancing infrastructure resiliency** by reviewing scaling thresholds and improving response options for high reconnect traffic scenarios. * **Improving workload isolation** to reduce the risk of workloads having a critical impact on production service paths. * **Improving agent reconnect handling** to reduce unnecessary resource consumption during reconnect events. * **Improving reconnect traffic management** to better distribute reconnect attempts during large-scale events. * **Enhancing monitoring and alerting** to improve visibility into device connectivity, reconnect activity, service health, and related infrastructure signals. * **Expanding incident response runbooks** for connectivity degradation scenarios to support faster and more consistent mitigation.

Read the full incident report →

Started Jul 16, 2026, 01:59 PM UTC· resolved Jul 17, 2026, 06:05 PM UTC

1. investigating Jul 16, 2026, 01:59 PM UTC

   We are aware of a problem where Endpoint Backup v2 assets can experience slow or failed backups due to a "504 Gateway Timeout" error. 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. monitoring Jul 17, 2026, 03:58 PM UTC

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

3. resolved Jul 17, 2026, 06:05 PM UTC

   This incident has been resolved.

4. postmortem Jul 30, 2026, 01:24 PM UTC

   **Endpoint Backup v2 - Backup delays and failures were caused by 504 Gateway Timeout errors – 2026-07-16** **Summary:** Between **2026-07-16 09:00 AM UTC** and **2026-07-17 03:30 PM UTC**, Endpoint Backup v2 customers experienced slow or failed backups due to a "504 Gateway Timeout" error. **Root Cause:** Increased activity and maintenance across multiple storage systems created higher-than-normal demand on infrastructure resources, resulting in backup performance issues for some customers. **Incident Timeline:** * Identified: **2026-07-16 09:00 AM UTC** * Public Notification: **2026-07-16 02:59 PM UTC** * Resolved: **2026-07-17 03:30 PM UTC** **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps. * We are implementing performance improvements, enhancing monitoring and alerting capabilities for faster issue detection, and adding safeguards to better manage demand and maintain service stability during periods of increased activity.

Read the full incident report →

Started Jul 15, 2026, 08:56 AM UTC· resolved Jul 15, 2026, 08:56 AM UTC

1. resolved Jul 15, 2026, 08:56 AM UTC

   We experienced a partial service disruption affecting access to KaseyaOne from 02:55 AM ET to 03:30 AM ET. KaseyaOne services are now fully operational, and we are continuing to monitor the environment to ensure stability. We apologize for any inconvenience this may have caused. - Kaseya Cloud Operations Team

2. postmortem Jul 20, 2026, 04:36 PM UTC

   # Root Cause Analysis - KaseyaOne - Portal Login Outage – 2026-07-15 ## Summary: Between 2026-07-15 06:54 UTC and 2026-07-15 07:16 UTC, KaseyaOne customers were unable to login to KaseyaOne and access any downstream modules through SSO, such as the Kaseya Helpdesk. ## Root Cause: A scaling configuration was mistakenly changed during post-release infrastructure work, leaving the production application running with fewer resources than intended. When the remaining instance later experienced a routine restart, the application became unavailable because insufficient resources were available to maintain service. Restoring the correct infrastructure configuration resolved the issue. ## Incident Timeline: * Identified: 2026-07-15 06:54 UTC * Resolved: 2026-07-15 07:16 UTC * Public Notification: 2026-07-15 08:56 UTC ## Preventative Measures: To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps: ### Enhancements to Infrastructure Governance * Reinforce the use of Infrastructure as Code \(IaC\) as the authoritative source for production infrastructure changes. * Eliminate manual production configuration updates outside approved deployment processes. * Establish automated controls to ensure production configurations remain aligned with approved infrastructure definitions. ### Enhancements to Release Management Practices * Require enhanced review procedures for infrastructure platform and provider upgrades that may trigger configuration reconciliation. * Implement pre-deployment validation of critical production endpoints before infrastructure changes are applied. * Strengthen change review requirements for production edge-routing and traffic-management components. ### Enhancements to Infrastructure Resiliency * Implement automated configuration drift detection and reporting to identify discrepancies between deployed infrastructure and source-controlled configurations. * Add regular validation of externally facing routing and origin configurations. * Improve recovery validation procedures to account for platform propagation delays and ensure service restoration is fully confirmed before incident closure. ### Enhancements to Incident Management and Response * Introduce additional deployment validation procedures for infrastructure changes affecting customer-facing services. * Expand post-deployment verification activities to include end-to-end application availability testing. * Continue refining incident response processes to further accelerate restoration activities.

Read the full incident report →

Started Jul 11, 2026, 04:07 PM UTC· resolved Jul 13, 2026, 12:26 PM UTC

1. investigating Jul 11, 2026, 04:07 PM UTC

   We are aware of a problem where some customers across multiple pods are experiencing backup performance degradation for various services. The affected pods and services are listed below. 'gbe2-pod-0' - SharePoint 'gbe2-pod-1' - SharePoint 'use1-pod-4' - SharePoint 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. monitoring Jul 12, 2026, 12:13 PM UTC

   A fix has been implemented and we are monitoring the results. Several pods have shows signs of improvement.

3. resolved Jul 13, 2026, 12:26 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 08, 2026, 12:37 PM UTC· resolved Jul 22, 2026, 02:18 PM UTC

1. investigating Jul 08, 2026, 12:37 PM UTC

   We are aware of a problem where some customers hosted on pod 'gbe2-saas-p0' are experiencing backup performance degradation for some SharePoint and Teams 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. monitoring Jul 08, 2026, 02:05 PM UTC

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

3. monitoring Jul 09, 2026, 12:24 PM UTC

   We are continuing to monitor for any further issues.

4. monitoring Jul 13, 2026, 07:55 PM UTC

   Our R&D team has implemented additional changes to further address this issue. SharePoint services have recovered and our R&D team continues to monitor as Teams backup success rates improve.

5. monitoring Jul 17, 2026, 02:12 PM UTC

   Backup success rates for Teams have returned to normal. All other services continue to backup normally. Our R&D team is continuing to monitor for any other issues.

6. resolved Jul 22, 2026, 02:18 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 06, 2026, 01:33 PM UTC· resolved Jul 07, 2026, 01:06 PM UTC

1. identified Jul 06, 2026, 01:33 PM UTC

   We are aware of a problem where Pod 'aue1-bfyii-2746' is inaccessible. The Kaseya R&D Team has identified the problem and are working toward a fix. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Jul 07, 2026, 12:38 PM UTC

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

3. resolved Jul 07, 2026, 01:06 PM UTC

   This incident has been resolved.

4. postmortem Jul 22, 2026, 04:25 PM UTC

   ## Root Cause Analysis – Service Interruption Affecting SaaS Protection Node 'aue1-bfyii-2746' **Summary** Customers hosted on node **aue1-bfyii-2746** experienced a service interruption that prevented access to their Datto SaaS Protection accounts. During the outage, affected customers were unable to perform backup, restore, or export operations. The interruption occurred after the storage infrastructure supporting the node reached full capacity, causing services hosted on the node to become unavailable. Service was restored after additional storage capacity was provisioned and the environment was validated to be operating normally. **Root Cause** This incident was caused by the storage infrastructure supporting node **aue1-bfyii-2746** reaching maximum capacity. Once available storage was exhausted, services hosted on the node became unavailable, preventing customers from accessing backup and recovery data or initiating backup, restore, and export operations. Monitoring systems identified that the node was approaching critical storage utilization levels on **2026-06-29 18:02 UTC**, providing advance indication of a capacity risk. However, the planned storage expansion was not completed before available capacity was exhausted due to process gaps between monitoring, alerting, tracking, and remediation activities which delayed the infrastructure capacity expansion required to prevent the disruption resulting in a service interruption for customers hosted on the affected node. Following identification of the outage, additional storage capacity was provisioned and validated. Service was restored after verification confirmed normal operation of the affected environment. **Incident Timeline** **Preventative Measures** To reduce the likelihood and impact of similar incidents, we are implementing the following improvements: **Monitoring and Alerting** * Review and enhance storage-capacity thresholds to provide additional lead time before critical utilization levels are reached. * Implement automated escalation procedures when projected capacity consumption exceeds defined risk thresholds. * Increase visibility into storage growth trends and capacity forecasting across the platform. **Incident Management and Response** * Establish a standardized end-to-end process for capacity expansion activities with clearly defined ownership and accountability. * Improve coordination and tracking of infrastructure remediation efforts across teams. * Introduce governance checkpoints to ensure capacity-related risks are addressed within established timelines. **Infrastructure Operations** * Strengthen processes for planning and executing storage-capacity expansions. * Improve tracking and visibility of infrastructure upgrade activities from initiation through completion. * Conduct regular reviews of capacity-planning practices to better align infrastructure growth with platform demand. **Infrastructure Resiliency** * Perform a proactive review of storage utilization across the Datto SaaS Protection environment. * Prioritize capacity-expansion activities for systems approaching critical utilization thresholds. * Continue investing in platform resiliency and scalable infrastructure to support future growth.

Read the full incident report →

Started Jul 03, 2026, 05:06 PM UTC· resolved Jul 06, 2026, 01:04 PM UTC

1. investigating Jul 03, 2026, 05:06 PM UTC

   We are currently aware of a problem where Uniview is not loading assets for some customers. 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 Jul 03, 2026, 05:29 PM UTC

   The Kaseya R&D team has found the problem and deployed a fix. They are closely monitoring the situation to confirm resolution.

3. monitoring Jul 03, 2026, 05:29 PM UTC

   We are continuing to monitor for any further issues.

4. monitoring Jul 03, 2026, 06:34 PM UTC

   After monitoring the deployed fix, the Kaseya R&D team has observed that Uniview performance has returned to normal and is now reliably loading assets again. We believe this issue to be resolved but will continue monitoring over the weekend to ensure resolution.

5. resolved Jul 06, 2026, 01:04 PM UTC

   The Kaseya R&D team has completed monitoring and confirmed that Uniview performance remains stable. Assets are loading normally, and no further issues related to this incident have been observed. We consider this issue fully resolved at this time. If you experience any new issues, please contact our Chat Support so we can investigate promptly. For ongoing visibility into service status and communications, we encourage you to subscribe to the Kaseya Status Page: status.kaseya.com Thank you for your understanding and continued support.

6. postmortem Jul 08, 2026, 04:20 PM UTC

   **Endpoint Backup v2 – UniView Not Loading EBv2 Assets or Tenets – 2026-07-03** **Summary:** Between 2026-07-03 17:06 UTC and 2026-07-03 18:34 UTC, Endpoint Backup v2 customers experienced an issue where UniView can fail to load the homepage or Endpoint Backup v2 assets. **Root Cause:** The Endpoint Backup application restarted; however, a critical supporting process that is required to be consistently available was not present in its expected completed state. As a result, the Endpoint Backup V2 service was unable to initialize properly, leading to a temporary disruption of functionality. All other services remained stable and continued to operate as expected. **Incident Timeline:** * Identified: 2026-07-03 17:06 PM UTC * Public Notification: 2026-07-03 17:19 UTC * Resolved: 2026-07-03 18:34 UTC **Preventative Measures:** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps: * Established additional pre-deployment verification processes to ensure configuration accuracy and minimize the likelihood of deployment-related disruptions. * To improve detection and reduce time to identify service disruptions, we are developing synthetic tests that continuously monitor EBv2 availability and validate the critical end-to-end workflows required for UniView to load EBv2 assets successfully.

Read the full incident report →

Started Jul 03, 2026, 01:58 PM UTC· resolved Jul 03, 2026, 03:47 PM UTC

1. investigating Jul 03, 2026, 01:58 PM UTC

   We are aware of an issue affecting Autotask users hosted in the UK02 zone, resulting in increased latency and delays in workflow rule processing. The Kaseya R&D Team is actively investigating this issue. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. identified Jul 03, 2026, 03:05 PM UTC

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

3. monitoring Jul 03, 2026, 03:18 PM UTC

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

4. resolved Jul 03, 2026, 03:47 PM UTC

   This incident has been resolved.

5. postmortem Aug 25, 2026, 03:20 PM 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.

Read the full incident report →

Started Jul 01, 2026, 08:18 PM UTC· resolved Jul 01, 2026, 08:45 PM UTC

1. investigating Jul 01, 2026, 08:18 PM UTC

   We are aware of a problem where customers hosted on node 'des1-bfyii-1701' are currently unable to access their accounts. The Kaseya R&D Team is currently investigating. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

2. monitoring Jul 01, 2026, 08:24 PM UTC

   Our R&D team has identified the issue and have implemented a fix. The team is monitoring for any other issues.

3. resolved Jul 01, 2026, 08:45 PM UTC

   This incident has been resolved.

Read the full incident report →