DRMM (Syrah) -- Device Filter "Site Name" criterion ignored, returns devices from all sites

Update timeline

1. investigating Jul 31, 2026, 12:48 AM UTC

   We are aware of the issue where Filters no longer respect the "Site Name" Criteria resulting in devices that should not be included in the Filter are included in the Filter that then affects Policy/Job targeting.

2. investigating Jul 31, 2026, 02:04 AM UTC

   We are continuing to investigate this issue.

3. monitoring Jul 31, 2026, 02:30 AM UTC

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

4. resolved Jul 31, 2026, 03:26 AM UTC

   This incident has been resolved.

5. postmortem Aug 05, 2026, 12:53 PM UTC

   **Datto RMM - Global Filters Using Site Criteria Returned Incorrect Results – 2026-07-30** **Summary** Between **2026-07-30 18:10 UTC** and **2026-07-31 02:30 UTC**, some **Datto RMM** customers experienced an issue where **Global Filters using Site specific criteria, including Site Name**, **Site Description**, or **Site is On-Demand,** and **excluding “does not contain”** criteria, returned broader-than-expected device results. As a result, customers using the affected filter configurations may have seen devices incorrectly included in filter results, creating a risk of inaccurate device targeting for downstream automation, policies, or jobs that ran during the exposure window. The time required to fully restore service was extended because a rollback path for the release was not available. As a result, mitigation required the issue to be diagnosed, a software fix to be developed, tested, and deployed before the incident could be resolved. Engineering isolated the regression, developed a corrective code change, validated the fix, and deployed it to restore expected filter behavior. ‌ **Root Cause** A software defect introduced during a performance optimization of site-based filtering logic caused certain filter criteria to be processed incorrectly. Under specific filter configurations, portions of the filtering logic were not applied as intended, resulting in broader device selection results than expected. A corrective code change was validated and deployed to restore expected filter behavior. ‌ **Incident Timeline** **Identified:** 2026-07-31 00:30 UTC **Public Notification:** 2026-07-31 01:48 UTC **Resolved:** 2026-07-31 02:30 UTC ‌ **Preventative Measures** To reduce the likelihood and impact of similar incidents in the future, we are taking the following steps: **Enhancements to Release Management Practices** * Expand unit test coverage for code changes to improve validation of functionality affected by application changes. * Expand automated regression test coverage across filter functionality, including historical defect scenarios and previously identified filter-related use cases. * Increase automated test coverage for critical customer workflows and core platform functionality to improve release readiness validation. * Execute automated regression testing as part of both development and release validation processes. * Evaluate additional release strategies such as customer beta testing, canary deployments, and blue/green deployments to enhance existing release strategies and further reduce risk, improve early issue detection, and minimize customer impact during software releases. **Enhancements to Quality Assurance and Detection** * Implement additional automated regression testing for filter functionality and related workflows. * Additional scope will be added to automated Regression testing that covers functional completeness and accuracy to cover critical customer workflow validation * Expand monitoring and alerting around post-deployment validation activities to accelerate identification of release-related issues. * Establish automated validation of key customer workflows following deployment to improve early detection of functional regressions during QA testing. **Enhancements to Incident Recovery Capabilities** * Implement automated post-deployment validation of critical workflows and use resulting signals to accelerate mitigation decisions when issues are detected post-release. * Develop rollback capabilities to enable restoration to a known good release version when appropriate. * Assess rollback mechanisms that align with future deployment strategy improvements, including staged deployment and service-based release models. These improvements are intended to strengthen release validation, improve early detection of functional regressions, reduce restoration time during incidents, and limit the potential impact of future release-related issues.