Datto incident
Datto RMM - Vidal - Filter loading error "Out of sort memory"
Datto experienced a minor incident on March 30, 2026 affecting Vidal (US East), lasting 38m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- 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/
- monitoring Mar 30, 2026, 07:51 PM UTC
A fix has been implemented and we are monitoring the results.
- resolved Mar 30, 2026, 08:20 PM UTC
This incident has been resolved.
- 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.