Kaseya Inc Incident History

This incident has been resolved.

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

We are aware of an issue affecting the Merlot platform where Quick Jobs and Scheduled Jobs are failing to run. The Kaseya Engineering Team is actively 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/

This incident has been resolved.

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

We are investigating reports of slow loading times affecting Workplace, the web portal, and agent connectivity for partners hosted in our US regions. A small number of users may also see intermittent connection errors when opening a project or folder. Our engineering 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/

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

This incident has been resolved.

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

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/

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/

**Root Cause Analysis – DRMM Agent Services Incorrectly Flagged by Endpoint Security Software**  **Summary**  Between **2026-07-30 17:00 UTC and 2026-07-31 18:43 UTC**, some Datto RMM customers on the Syrah platform experienced issues following the deployment of agent version **15.1.0**. The issue affected endpoints utilizing **Sophos**, where certain DRMM agent services were identified as malicious. In affected environments, agent files were quarantined or removed, causing the Datto RMM agent to become non-functional until remediation actions were completed.  The issue affected a subset of customers and was resolved after coordination with the security vendor.  **Root Cause**  Following the deployment of DRMM agent version 15.1.0, certain agent components were incorrectly identified as malicious by a third-party endpoint security vendor. The detection was a false positive and was not the result of malware or unauthorized code within the DRMM agent. Investigation determined that the detection was likely related to changes in the digital signing reputation of the agent files, which caused the security tool to classify legitimate agent activity as suspicious.  **Incident Timeline**  * **Identified:** 2026-07-30 21:00 UTC  * **Public Notification:** 2026-07-31 02:27 UTC  * **Resolved:** 2026-07-31 18:43 UTC  **Preventative Measures**  To reduce the likelihood and impact of similar incidents in the future, we are implementing the following improvements:  **Enhancements to Release Validation**  * Further strengthen our pre-release validation by incorporating a broader set of security and threat-intelligence platforms before agent updates are broadly deployed.  * Broaden third-party endpoint security testing to further improve early detection of potential false-positive classifications before release.  **Enhancements to Vendor Coordination**  * Expand the existing file reputation submission process to include additional security providers to further improve coordination and response options, reducing reliance on a single vendor path.  * Establish more formalized engagement processes with security vendors to facilitate faster review and resolution of false-positive detections.  **Enhancements to Agent Deployment Practices**  * Evaluate staged agent rollout capabilities that would allow updates to be gradually deployed to a subset of endpoints before broader distribution limiting the scope of impact when issues are detected.  * Use phased deployments to identify unexpected environmental interactions earlier and further reduce potential customer impact.  **Enhancements to Agent Update Architecture**  * Review and improve elements of the agent update mechanism to reduce the likelihood that normal update activities are misinterpreted by security software.  * Continue refining update workflows to improve compatibility with modern endpoint protection technologies to further reduce the risk of false positive classifications

This incident has been resolved.

We have reached out and shared the necessary technical indicators with our third party contact and have received confirmation that corrective actions have been implemented on their side. Based on the information provided to us, the issue should no longer occur with the current version of the agent. We will continue to closely monitor the situation and provide additional updates if necessary. Thank you for your patience and understanding.

Our R&D team is continuing its investigation into this issue and is working closely with a third-party provider to assist in identifying the root cause and resolution.

We are aware of a problem where, after the Datto RMM 15.1.0 update on the Syrah platform, some anti-virus software may flag the Datto RMM service as malicious. The Kaseya Engineering Team is investigating this issue. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

Backup operations remain healthy, with success rates staying high across all services and regions following the recent changes. Work on the EWS to Microsoft Graph API migration is ongoing, and our R&D team continues to monitor for any further issues.

Our R&D team has completed deployment of the latest changes for the Graph API components as part of the ongoing migration and backup success rates for all services across all regions remain high. We are continuing to monitor.

Backup success rate metrics for all services across all regions continue to remain stable at normal levels. Our R&D team is actively completing deployment of additional improvements to all regions and they are continuing to monitor.

Backup success rate metrics for all services across all regions have recovered and remain stable at normal levels. Google services, along with OneDrive and SharePoint, continue to process 3x daily backups while Teams and Exchange services remain temporarily set to 2x daily backups to maintain high success rates as the migration to Microsoft Graph APIs progresses. Our R&D team is continuing to monitor.

Our R&D team has deployed additional improvements, and backup cadence has now been restored to 3x daily backups for all Google services, OneDrive, and SharePoint across all regions. Exchange and Teams backup cadence remains temporarily set to 2x daily backups to help maintain high backup success rates during the ongoing transition to Microsoft Graph APIs. We have observed continued improvement in backup performance following these changes, and our R&D team is closely monitoring backup success rates across all affected regions. Additional performance enhancements are currently being deployed to further reduce API throttling, improve backup performance, and accelerate recovery. Deployment of these changes is expected to be completed early next week.

Datto SaaS Protection is currently experiencing degraded backup performance and missed backups for some Microsoft 365 services across multiple regions. The issue has been linked to increased API activity and application-level throttling associated with the ongoing transition from Exchange Web Services (EWS) to Microsoft Graph APIs. Affected regions: US (USE/USW) Australia (AUE) Canada (CAE) Germany (DES) UK (GBE) Singapore (SG) Our R&D teams have identified the primary contributing factors and are actively working to restore full service functionality. Multiple mitigation measures have been implemented, including application performance optimizations, infrastructure and capacity improvements, deployment of configuration changes across affected SaaS Protection pods, and a temporary reduction in backup cadence from 3x daily backups to 2x daily backups to help reduce API demand and improve backup success rates during the transition. These actions have resulted in measurable improvement, with backup success rates increasing across all affected regions over the past 24 hours. While performance continues to stabilize, some customers may still experience backup delays or missed backups as remediation efforts continue. Additional software enhancements are scheduled for deployment this week to further reduce API throttling, improve backup performance, and accelerate recovery. Customer data protection remains the highest priority, and our R&D teams continue to closely monitor the environment while implementing further improvements. Updates will continue to be provided through the Kaseya Status Page as progress is made toward full service restoration.

This incident has been resolved.

We are no longer seeing errors related to the ConnectWise Integration. We are continuing to monitor the services at this time.

We are aware of a problem where the ConnectWise integration is returning an error on our Vidal platform. Users may see errors while viewing the integration page and ticketing can be affected. The Kaseya Engineering Team is currently Investigating this 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/

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

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

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

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/

This incident has been resolved.

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

A database issue is causing a partial outage on the US Inky dashboard. Email processing is unaffected but settings will not be able to be changed while we correct the issue. The issue has been identified and a fix is being implemented.

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

This incident has been resolved.

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

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.

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

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

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

This incident has been resolved.

We are continuing to monitor for any further issues.

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

The Kaseya R&D Team has implemented a fix to alleviate backups for customers hosted on the node des1-bfyii-1127. Backups success rates will be monitored for improvement

We are aware of a problem where SaaS Protection customers hosted on node ‘des1-bfyii-1127' are experiencing degraded backup performance for some services. The Kaseya R&D Team has identified the issue and are working to resolve it. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

This incident has been resolved.

We are aware of a problem where some customers are unable to access Autotask within our Sydney Data Center 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/

This incident has been resolved.

We are continuing to monitor for any further issues.

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

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

We are aware of a problem where Partners have reported the inability to log into the portal via Kaseya One The Kaseya R&D Team is investigating the issue. In the meantime, a workaround of logging directly into the ConnectBooster portal via the primary URL can allow you to log in without Kaseya One. please create a ticket with our Support team or contact them at 833-863-2237 if you need assistance with this process. Subscribe to the Kaseya Status Page for up-to-date information at https://status.kaseya.com/

A known issue exists where archived agents may continue to generate sync completion alerts when associated local points are marked as offsite, despite the agents being in an archived state. While a long-term solution is scheduled for implementation in a future release, assets affected before the fix is deployed will need to be corrected through manual intervention. Customers seeking to implement this mitigation should submit a request through the Kaseya Help Desk Portal at https://helpdesk.kaseya.com/hc/en-gb. Our Support team will assist with the required remediation activities. Thank you for your understanding and continued support.

This incident has been resolved.

Our payment provider for KaseyaOne and Kaseya Store has identified intermittent connectivity issues with our fraud prevention provider that might cause increased authentication declines. During this time, users may experience intermittent issues related to payment processing in KaseyaOne and Kaseya Store. Core platform functionality outside of payment services will remain unaffected. We recommend avoiding payment-related actions during this maintenance window where possible. We will monitor the situation and provide updates if necessary.

This incident has been resolved.

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

We are aware of a problem where customers using Datto Endpoint Backup for PC and paired with 'use1-dtc-server-5.datto.com' may encounter reduced performance or intermittent issues with 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/

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

This incident has been resolved.

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

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/

Significant improvement to backup success rate metrics has been observed across all regions after the latest changes were implemented. Our R&D team is continuing to deploy configuration changes to further stabilize backup performance in all regions. Backup success rates will continue to be closely monitored as the team is actively working to develop additional improvements to address the API throttling related to the transition from EWS to Microsoft Graph APIs currently in progress.

The latest changes have been deployed to SaaS Protection pods in multiple regions still experiencing backup performance issues. Our R&D team is continuing to monitor as backup success rate metrics improve across the fleet.

Our R&D team is currently implementing configuration changes in multiple regions to further mitigate the degraded backup performance still affecting some customers. We will be closely monitoring the results of these changes as we continue to develop additional improvements to accelerate recovery for affected customers.

After the changes made yesterday, we have observed some improvement to backup success rates however backups are currently still degraded for some M365 services across multiple regions due to API throttling related to the transition from EWS to Microsoft Graph APIs. Our R&D team is continuing to develop additional improvements to address the backup performance issues.

Our R&D team has completed deployment of the configuration changes to SaaS Protection pods in all regions. Daily backup cadence is now temporarily set to 2x backups per day across the fleet to reduce API throttling and help stabilize backup success rate metrics during the transition from EWS to Microsoft Graph APIs. Our R&D team is closely monitoring the effects of the changes and expect backup success rates to begin stabilizing over the next several hours.

Our R&D team is continuing to deploy the configuration changes to adjust backup frequency from 3x backups per day to 2x backups per day on SaaS Protection pods in all regions and we are continuing to closely monitor backup success rate metrics.

Our R&D team has begun deployment of the changes to reduce backup cadence on affected SaaS Protection pods across all regions to 2x backups per day to help stabilize backup success rates further. This change is expected to complete deployment by 20:00 ET (00:00 UTC). Our R&D team is continuing to closely monitor backup performance as these additional changes are implemented.

Our R&D team continues to address backup performance issues affecting some Microsoft 365 services across multiple SaaS Protection pods following the transition from EWS to Microsoft Graph APIs. To help stabilize backup success rates and reduce API throttling during this migration, backup cadence on affected pods will be temporarily reduced from 3x backups per day to 2x backups per day.

Our R&D team is continuing to address the backup performance issues affecting some M365 services on multiple SaaS Protection pods. In the meantime, they are preparing to temporarily reduce backup cadence on affected pods from 3x backups per day to 2x backups per day to help stabilize backup success rates in all affected regions.

Our R&D team has released a fix to address the backup performance degradation for some M365 services affecting customers hosted in multiple regions and they are closely monitoring.

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

We are aware of an issue where some Datto SaaS Protection customers across multiple regions may experience degraded backup performance for some M365 services. Affected regions: AUE CAE DES GBE SG USE The Kaseya R&D team has identified the issue and is actively working to restore normal backup performance as quickly as possible. For the latest updates, please subscribe to the Kaseya Status Page at https://status.kaseya.com/.

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

This incident has been resolved.

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

We are continuing to investigate this issue.

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.

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

This incident has been resolved.

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

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

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/