Dixa Status

Data ingestion has fully caught up and the Real-Time Dashboard, Search and Conversations pages are showing live data again.

## **Summary** On April 8, 2026, Dixa experienced a partial outage lasting approximately 58 minutes. New WebSocket connections were unable to be established, which meant that new logins failed, and any agents who refreshed their browser or lost their connection could not reconnect. Agents who remained on an existing session were unaffected during the incident. The root cause was a TLS certificate misconfiguration introduced during a planned migration of our ingress controller infrastructure. The issue was identified, fixed, and fully resolved within the hour. ## **Impact** Between 18:26 and 19:24 CEST, customers attempting to log in to Dixa or re-establish a WebSocket connection \(e.g., after a page reload\) were unable to do so. Browsers rejected the connection due to an invalid TLS certificate being served. Agents who were already logged in with an active WebSocket session continued to operate normally throughout the incident. The impact was limited to new or reconnecting sessions. A small number of customers were affected and reported the issue to our support team. No conversations or data have been lost during the incident. ## **Timeline \(CEST\)** * 18:26 - Internal reports that Dixa is not loading for some users * 18:30 - Issue escalated to engineering via our critical support channel * 18:32 - Status page updated to **Investigating** * 18:40 - Engineering identifies a TLS certificate error \(`ERR_CERT_AUTHORITY_INVALID`\) * 18:52 - Root cause identified, a self-signed default certificate was being served instead of the correct one * 19:00 - Status page updated to **Identified** * 19:11 - Fix deployed; WebSocket connections begin recovering * 19:12 - Status page updated to **Monitoring** * 19:24 - Full recovery confirmed; status page updated to **Resolved** ## **Root Cause** As part of our ongoing WebSocket resilience work to ensure a more stable platform, we migrated our ingress controller \(the component that routes incoming traffic to internal services\) from an end-of-support solution to a new one. This migration was tested in our staging environment before being applied to production. However, there was a configuration discrepancy between staging and production for the ingress class that handles WebSocket traffic. When DNS was switched to the new ingress controller on the morning of April 8, existing connections continued to work through cached DNS entries still pointing to the old controller. Hours later, as DNS caches expired across the internet, clients began resolving to the new controller, which, due to the misconfiguration, did not recognize the WebSocket routes. This caused it to serve a default self-signed TLS certificate instead of the valid one, leading browsers to reject the connection. The length of the partial outage per customer varies depending on when the DNS cache expired, and if WebSocket connections started to connect to the new load balancer. ## **Resolution** Once the root cause was identified, a configuration update was deployed to the new ingress controller so that it could correctly handle WebSocket traffic. Connections began recovering immediately after the fix was applied. ## **Preventive Measures** We have taken the following steps to reduce the likelihood and impact of similar issues in the future: * **Environment parity:** All non-production environments have been aligned with production configuration conventions, eliminating the discrepancy that caused this incident. * **Endpoint monitoring:** We have added external monitoring checks that validate both the availability and TLS certificate validity of our WebSocket endpoints. This will enable faster detection if a similar issue occurs. * **WebSocket isolation**: We will isolate the platform's WebSocket requirement to be optional, so if a similar issue should happen in the future, the disruption will be less intrusive for users. ‌ ‌ We sincerely apologize for the disruption this caused. Reliability is a top priority for us, and we are committed to learning from every incident to make Dixa more resilient. If you have any questions, please don't hesitate to reach out to your account team or our support at [friends@dixa.com](mailto:friends@dixa.com).

_Dixa experienced issues with the Smart Reply feature in AI CoPilot on 18 March 2026._ _**Summary**_ _18 March 2026 at 14:37 CET - 20:20 CET, customers experienced issues with the Smart Reply feature in AI CoPilot. Agents were unable to use Smart Reply._ _**Root cause**_ _A code change introduced a regression that caused agents' browsers to block completing the request to load Smart Reply suggestions._ _**Timeline**_ _At 14:37 CET on 18 March 2026: Issue flagged internally after several customers reported the issue_ _At 15:33 CET: Engineering investigates and attempts an initial rollback, which does not resolve the issue._ _At 16:02 CET: Status page updated to "Investigating" — customers notified of difficulties with AiCoPilot Smart Replies._ _At 16:48 CET: Status page updated — engineering continues to investigate._ _At 18:17 CET: Status page updated — root cause investigation ongoing_ _At 20:20 CET: The knowledge-backend service is successfully rolled back to a stable version, restoring Smart Reply._ _At 20:52 CET: Status page updated to "Resolved" — all known issues confirmed resolved._ _**Solution**_ _The immediate solution was to roll back to a stable version from prior to the breaking change, restoring Smart Reply for all affected customers._ _Long term, the team will review the offending commit before re-deploying to prevent similar regressions from reaching production undetected._ _We sincerely apologise for the inconvenience caused by this issue._

**Summary:** On March 11, 2026, Dixa experienced platform-wide degraded performance lasting approximately 3 hours \(08:30 - 12:35 CET\). Customers experienced slow or failed conversation loading, timeouts on email sending, conversation transfers, assignments, and flow processing. No data was lost, and there were no security issues at any point. **Impact:** * _Availability_: Platform-wide slowness and partial inaccessibility for ~3 hours. * _Affected functionality_: Conversation loading, email sending, conversation transfers, conversation assignments, and flow processing - all experienced significant slowness and intermittent failures. * _Data integrity:_ All emails were fully processed after the fix. No data was lost, and no security issues occurred at any point. **Root Cause:** The incident was caused by an atypical traffic pattern in inbound email processing that resulted in repeated internal retries - retries are a normal part of email distribution, accounting for factors such as sending delays and server availability, but this expanded exponentially. The sustained retry volume placed excessive load on a central platform component, causing cascading timeouts across dependent services and resulting in platform-wide degradation. **Timeline \(CET\):** * Mar 11, 06:00 - First signs of email processing errors detected * Mar 11, 08:30 - Platform degradation begins; customer impact starts * Mar 11, 10:50 - First mitigation deployed; partial improvement * Mar 11, 12:30 - Root cause fully identified; final fix applied * Mar 11, 12:35 - Platform stability confirmed **Resolution:** We identified and addressed the source of the abnormal email volume, which resulted in an immediate reduction in error rates, and the platform to recover. **What We Have Done Since This Incident:** Following this incident, we have already implemented the following improvements: 1. Added validation to reject invalid email addresses early in the pipeline, preventing them from entering retry loops. 2. Optimised internal lookups to fetch only necessary data instead of the full conversation history, significantly reducing load during email processing. 3. Added deduplication logic to prevent redundant data fetches during email processing. 4. Enforced concurrency limits: platform components now shed excess traffic when saturated, allowing requests to be redistributed rather than queued indefinitely. 5. Added deadline checking: expired requests are now discarded immediately instead of consuming resources on work that is no longer needed. 6. Reduced internal timeout thresholds to fail fast under contention rather than blocking for extended periods. **What We're Continuing to Work On:** 1. Loop detection and interruption - Introduce mechanisms to detect and automatically halt email processing anomalies before they can accumulate significant load. 2. Improved alerting and escalation - Ensure processing anomalies are detected and escalated with appropriate urgency. **Closing Note:** We sincerely apologize for the disruption this caused. These improvements are our highest priority. If you have any questions, please reach out to [friends@dixa.com](mailto:friends@dixa.com).

**Summary**: On March 10, 2026, all public Dixa Knowledge Help Centers were unavailable following a production deployment performed during scheduled maintenance. **Impact** * Dixa Knowledge Public Help Centers remained inaccessible for 6 hours \(approximately\) * Customers with advanced custom CSS styling were contacted directly with instructions on how to update their selectors to prevent recurrence. **Root Cause:** After the production deployment performed during a scheduled maintenance, all public Help Centers became unavailable. Visitors saw an error page \(500\) instead of help content. **Timeline \(CET\)** Mar 10, 08:00 - Maintenance completed. No anomalies detected. Mar 10, 11:52 - Initial customer reports received. Considered isolated cases at the time. Mar 10, 13:38 - Incident process triggered. Reported on Status page. Mar 10, 13:57 - Root cause fully identified. Mar 10, 14:13 - Fix deployed. Public Help Centers restored; some styling issues persisted. Mar 10, 14:48 - Root cause for styling anomalies identified as linked to build-time generated class names. Affected customers notified with instructions. Mar 10, 18:03 - Incident resolved. **Resolution**: We identified a misconfiguration in the deployment that caused Help Centers to attempt to load from a test environment rather than production. A fix was deployed, and an immediate reduction in error rates confirmed it was effective. **What We Have Done Since This Incident:** Following this incident, we have already implemented the following improvements: 1. Proactively contacted all affected customers with clear instructions on how to update their custom CSS styling. 2. Documented additional validations for future migrations and action plans to address similar errors. 3. External documentation updated to offer alternatives to the use of auto-generated classes for styling Help Centers. **What We're Continuing to Work On** * Improve monitoring and alerting, ensure availability issues are detected and escalated promptly, independent of customer reports. * Investigating a solution to expose stable, named elements for Help Center customization, reducing dependency on build-generated class names. **Closing Note:** We sincerely apologize for the disruption this caused. We appreciate your patience throughout this disruption. If you have any questions, please reach out to friends@dixa.com.

**Summary** On March 2, 2026, Dixa experienced platform-wide degraded performance lasting approximately 3 hours and 45 minutes. Customers experienced slow or failed conversation loading, timeouts on email sending, conversation transfers, assignments, and flow processing. No data was lost, and there were no security issues at any point. **Impact** * **Availability:** Platform-wide slowness and partial inaccessibility for ~3 hours 45 minutes. * **Affected functionality:** Inbound email processing, conversation loading, conversation transfers, conversation assignments, and flow processing — all experienced significant slowness and intermittent failures. * **Side effect:** Some inbound emails resulted in empty, queue-less conversations being created. These are safe to close or merge with the correctly processed follow-up conversation. * **Data integrity:** All emails were fully processed after the fix. No data was lost and no security issues occurred at any point. **Root Cause** The incident was caused by a significant and atypical spike in inbound conversations that fell well outside expected operational parameters. This unexpected volume put pressure on a central database component, which began throttling requests. The throttling then cascaded to other parts of the system, resulting in platform-wide slowness and temporary inaccessibility. **Timeline \(CET\)** Mar 1, 02:14 Significant and atypical spike in inbound conversations begins Mar 2, ~17:45 Database throttling begins; connection pools saturate Mar 2, 19:08 Incident declared; investigation begins Mar 2, 20:06Mitigation measures applied; investigation ongoing Mar 2, 20:18 Root cause identified Mar 2, 21:09 Fix deployed; error rates drop Mar 2, 21:17 Resolution confirmed Mar 2, 21:21Incident resolved **Resolution** We identified and addressed the source of the abnormal conversation volume, which immediately caused error rates to drop and the platform to recover. **What We're Doing to Prevent Recurrence** We have identified several systemic improvements and are actively working on them: 1. **Detect and suppress atypical inbound volume patterns** — Introduce early filtering to prevent abnormal spikes from reaching core platform components. 2. **Improve retry and backoff behaviour** — Reduce the risk of compounding load during high-traffic failure scenarios. 3. **Reduce inter-service dependencies** — Limit the blast radius of a single overloaded component affecting other parts of the platform. 4. **Improve database resilience** — Add circuit breakers and timeouts to prevent database pressure from cascading across services. 5. **Atomic conversation creation** — Ensure conversations are never persisted without their initial message, eliminating orphaned empty conversations as a failure side effect. **Closing Note** We sincerely apologize for the disruption this caused. We take platform reliability seriously and are committed to the systemic improvements outlined above. If you have any questions, please reach out to [friends@dixa.com](mailto:friends@dixa.com).

**Incident Summary** On Feb 20, 2026 - 15:24 CET, we experienced a brief period of degraded performance across the platform. Some customers may have noticed slower response times and intermittent timeouts while using the interface. **Impact** During the incident window, a subset of requests were delayed or failed, which may have affected normal usage for some customers. **Root Cause** The issue was caused by an internal service experiencing elevated load, which temporarily impacted request processing across the platform. **Resolution** Our engineering team identified the issue quickly and restored normal performance. The platform has been operating normally since the fix was applied. **Prevention** We are reviewing monitoring and scaling controls for the affected service to reduce the likelihood of similar incidents in the future.

Dixa experienced issues with transcription on Tuesday 27th January 2026 between 11:27 and 13:15 CET **Timeline** * At 10:22 CET / 4:22 EST Azure reports issues on the Azure OpenAI Service * At 11:27 CET / 5:27 EST the first issues with transcriptions start to happen at Dixa. At 11:46 CET / 5:46 EST Dixa investigates unrelated issues with live chats and calls. * At 12:16 CET / 6:16 EST While investigating the unrelated issues, Dixa noticed the issues with transcriptions. * At 13:15 CET / 7:15 EST Transcription issues disappear. **Impact** Transcriptions were not available or delayed in the specified timeframe. **Root cause** Our provider for AI voice transcriptions, Azure, reported issues. According to their [status](https://azure.status.microsoft/en-us/status/history/): _Between 09:22 UTC and 16:12 UTC on 27 January 2026, and again between 11:14 UTC and 13:35 UTC on 29 January 2026, a platform issue resulted in an impact to the Azure OpenAI Service in the Sweden Central region. Impacted customers may have experienced HTTP 500/503 errors, failed inference requests, and/or issues with model deployment metadata. This issue also affected the Agent Service and other downstream AI Services dependent on Azure OpenAI in this region._ **Immediate solution** We monitored the situation until it was fixed. **Long-term solution \(where applicable\)** We could consider changing region for our service if the issues become more frequent. Otherwise, Azure has been reliable enough to keep the current infrastructure. Furthermore, Azure made improvements on their side to prevent this situation from happening again.

All known issues to this incident have been resolved. We thank you for your patience and cooperation.

# **Degraded performance - AI Voice Transcription and webhooks** ## **Summary** On 22 December 2025, Dixa experienced an issue with the AI Voice Transcription feature. Transcriptions were not being generated for phone calls. Once the issue was resolved, a temporary period of degraded performance on Webhooks occurred as the system processed a backlog of pending transcriptions. ## **Root cause** Following a scheduled release, a component responsible for processing voice transcription requests stopped functioning correctly. When the issue was resolved, the system began processing all pending transcription requests. The high volume of these requests temporarily affected Webhook delivery times, causing delays in notifications to third-party integrations. ## **Timeline** **Monday 22 December at 11:30 CET:** Issue reported and investigation started. **Monday 22 December at 12:00 CET:** The issue was identified and a fix was deployed. AI Voice Transcription began processing again. **Monday 22 December at 12:26 CET:** Degraded Webhook performance identified, affecting some third-party integrations, including chatbots. **Monday 22 December at 12:54 CET:** AI Voice Transcription fully restored. **Monday 22 December at 14:35 CET:** All services fully recovered. Incident closed. ## **Preventive measures** Dixa will implement the following measures to prevent similar issues in the future: * Enhanced monitoring for the AI voice transcription feature. * Improved handling of backlog processing to minimise impact on dependent services. We sincerely apologise for the inconvenience this has caused.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.