ClaimConnect Service Disruption - Backend Database Queue Blocking

Summary

On July 15, 2026, DentalXChange experienced a service disruption affecting ClaimConnect, the DentalXChange website, and supporting backend services. A database queue table supporting cross-server communication for these services became locked at approximately 6:10 AM PT, and the resulting blocking condition cascaded across our web service infrastructure within minutes. The disruption was confirmed as client-facing by 6:26 AM PT and reported to our team by Client Services at 6:30 AM PT. Our team traced the condition to the database queue table and restarted the affected queue service at approximately 6:49 AM PT. Normal processing resumed by 6:57 AM PT, and Client Services confirmed full service restoration by 7:07 AM PT – approximately 57 minutes end-to-end from onset.

We understand the impact this disruption has had on your operations and are committed to transparency in our response. The corrective actions in this document are designed to prevent recurrence and to give us earlier warning before a similar issue can affect service again.

What happened

Our investigation found that the disruption was caused by a locking condition on a database queue table used for cross-server communication across our web service infrastructure, not by unusual client demand, a scheduled job, or a security event. We identified no indication that client or patient data was accessed, exposed, or improperly disclosed at any point during this incident.

This type of blocking condition has occurred in prior incidents on this system. Our engineering team has since narrowed the root cause to a specific step in an application workflow that writes to the shared database queue during a billing-related process. A fix for this workflow is already in progress and actively tracked, and we expect it to eliminate the recurring restarts this issue has previously required – including for other backend applications that share the same queue. We are also reviewing our monitoring coverage for this class of event to reduce time-to-detection going forward.

Root cause

Our investigation identified a locking condition on a database queue table that supports cross-server communication for ClaimConnect and supporting backend services across our web service infrastructure. When this table became locked, it prevented normal processing across the dependent servers, which presented to clients as a disruption across the infrastructure rather than a single-host failure. Monitoring shows the earliest failures appeared on individual web hosts (secure-connection and web-service checks) beginning at approximately 6:10 AM PT, followed within minutes by farm-wide errors as the contention propagated.

Restarting the affected queue service cleared the lock and restored normal processing. This pattern has occurred in prior incidents on this system. Our engineering team has since traced the root cause to a specific step in an internal application workflow that writes to the shared database queue during a billing-related charging process. A fix for this workflow is already in progress, assigned to our engineering team, and being tracked to completion; once deployed, it is expected to eliminate this source of database contention rather than requiring an ongoing tuning fix.

How we restored service

1. Identified that ClaimConnect, the DentalXChange website, and supporting backend services were affected across our web service infrastructure.
2. Confirmed the affected hosts and reviewed monitoring data to determine scope.
3. Traced the disruption to a locking condition on the database queue table responsible for cross-server communication.
4. Restarted the affected queue service to clear the blocking condition.
5. Confirmed normal processing resumed across all affected servers.
6. Verified service restoration directly with Client Services.
7. Continued monitoring to confirm sustained stability before closing the incident.

What we are doing to prevent recurrence

• Complete and deploy the engineering fix already identified and in progress for the application workflow responsible for the blocking condition. Target completion: 7/24/2026
• Establish a process to capture and share relevant query/technical details immediately following an incident, to accelerate root cause analysis for this class of issue. Target completion: 8/1/2026
• Evaluate separating key application functions into isolated application instances to reduce the blast radius of future database queue issues. Target completion: TBD, Scoping in progress.
• Improve time-to-detection for this class of event so that alerting triggers on the earliest underlying failure signals rather than on the customer-facing service check, which did not register until approximately 16 minutes after onset. Target completion: 8/1/2026

Questions

For questions about this incident or to request a technical briefing for your team, please contact your DentalXChange account representative or reach our support team through the usual channels.