Datto incident
Datto RMM - Merlot - Slow loading pages across the Web Application, Audit attempts are unsuccessful
Datto experienced a major incident on July 21, 2026 affecting Merlot (EU2), lasting 1d 2h. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- 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.
- monitoring Jul 21, 2026, 10:06 AM UTC
A fix has been implemented and we are monitoring the results.
- 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.
- monitoring Jul 21, 2026, 05:14 PM UTC
A fix has been implemented and we are monitoring the results.
- resolved Jul 22, 2026, 11:51 AM UTC
This incident has been resolved.
- 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.