Dixa Outage History

Started Oct 28, 2026, 10:48 AM UTC· resolved Oct 30, 2026, 04:24 PM UTC

1. investigating Oct 28, 2026, 10:48 AM UTC

   We’re investigating intermittent issues affecting incoming and outgoing Instagram messages in Dixa. Only some Instagram connections are affected, and Facebook Messenger is working as expected. We recommend checking whether your Instagram messages are coming through as usual. If they aren’t, please manage those conversations directly in your Meta account for now. Reconnecting your Instagram page to Dixa won’t resolve the issue at this time. We’ll share an update as soon as we have more information.

2. identified Oct 30, 2026, 10:37 AM UTC

   We’ve identified the cause of the intermittent issues affecting incoming and outgoing Instagram messages in Dixa. The issue is on Meta’s side and affects Instagram message delivery for some third-party connected accounts. Meta’s engineering team is actively working on a fix, and we’re in close contact with them. We’ll share an update as soon as Meta confirms a resolution.

3. monitoring Oct 30, 2026, 03:24 PM UTC

   Meta has informed us that the issue affecting Instagram message delivery for some connected accounts has been fixed, and our own testing confirms that incoming and outgoing Instagram messages are flowing through Dixa again. We’re keeping this incident open while we monitor to make sure the fix holds. If you were affected, please check that new Instagram messages are arriving in Dixa as expected. Messages received while the issue was ongoing (since 28 October) may not have reached Dixa, so we recommend reviewing your Instagram inbox directly in Meta for any conversations from that period. If you’re still seeing issues, please contact Dixa Support.

4. resolved Oct 30, 2026, 04:24 PM UTC

   All known issues to this incident have been resolved. We thank you for your patience and cooperation. Post mortem about this incident will be posted within 5 business days.

5. postmortem Nov 04, 2026, 11:08 AM UTC

   ## Summary Between 20 and 30 October 2026, some Instagram direct messages sent to our customers never reached Dixa. Meta, the company behind Instagram, had a fault that stopped it from passing these messages on to us. Meta confirmed the fault and fixed it on 30 October. Almost all affected accounts are receiving messages again. ## Who was affected The problem affected Instagram direct messages only. All other channels, including Facebook Messenger, worked normally. A small number of Instagram accounts stopped receiving messages. Some others received only part of their messages. When a message did not arrive, no conversation was created in Dixa, so your agents could not see it or reply to it. No messages were sent to the wrong place, and no data was exposed. Some affected accounts also had trouble sending replies on Instagram. This was a separate issue on Meta's side. ## Timeline All times are Copenhagen time. | Date | What happened | | --- | --- | | 20 October | The first Instagram account stopped receiving messages. Over the next week, more accounts followed. | | 27 October | Customers reported missing Instagram messages to our Support team. Our engineers started investigating the same day. | | 28 October | We conclued that Instagram was not sending us any messages for the affected accounts, and contacted Meta. | | 29 October | Meta confirmed the fault was on their side. | | 30 October, 07:24 | Messages started arriving again. | | 30 October, 15:12 | Meta confirmed the fault was fixed. | | 3 November | Most accounts are receiving messages again. We are working with Meta on the remaining accounts. | ## Why it happened When someone sends a direct message to your Instagram account, Instagram passes it on to Dixa. A fault on Meta's side stopped this for some Instagram accounts. Instagram simply stopped sending us the messages, so Dixa had nothing to receive. We carried out a thorough review of our own systems and found no issues. Dixa remained ready to receive messages throughout the incident, and no changes had been made on our side. Meta confirmed this on 29 October. It took a week to spot. Our monitoring looked for errors, and messages that never arrive do not cause errors. Many of the affected Instagram accounts also receive few messages, so a quiet inbox did not stand out as unusual. ## What we did * Checked all of our own systems to rule out a problem on Dixa's side. * Added extra tracking so we could see exactly which accounts were not receiving messages. * Reported the problem to Meta with detailed evidence and pushed for a fix. * Advised affected customers not to reconnect their Instagram accounts, on Meta's advice, as it would not help. As the fault originated within Meta’s systems, it was not something we were able to resolve directly. Meta implemented a fix on 30 October. ## What we are changing While we cannot prevent faults within Meta’s systems, we can significantly reduce the time it takes to detect them. To that end, we are introducing the following improvements: * **Automatic alerts.** We will be alerted when an Instagram or Facebook account that usually gets messages suddenly stops getting them. This means we can act before you notice. * **Better records.** We now keep a record of every message notification Meta sends us. This lets us show Meta exactly what is missing and get faster answers. * **Faster escalation.** We have found the quickest way to reach Meta's engineers and will use it first next time. ## What you should do now * **Check Instagram directly.** Messages sent to you between 20 and 30 October may be missing from Dixa. Open your Instagram inbox to find and answer them. * **No need to reconnect.** Your Instagram connection to Dixa does not need to be changed. * **Contact us if something looks wrong.** If your Instagram messages still are not arriving in Dixa, please contact Dixa Support. A small number of accounts are still affected, and we are working with Meta and the customers involved. We are sorry for the disruption this caused you and your customers. Thank you for your patience while we worked with Meta to fix it.

Read the full incident report →

Started Oct 23, 2026, 09:15 AM UTC· resolved Oct 23, 2026, 09:31 AM UTC

1. resolved Oct 23, 2026, 09:15 AM UTC

   On October 23, Dev API was unavailable from 11:15 to 11:31 CEST (16 minutes). The outage was caused by an error during a deployment step for one of our components. A postmortem will be published within 5 business days.

2. postmortem Oct 27, 2026, 07:37 AM UTC

   ## Summary On October 23, 2026, at 11:15 AM CEST, all requests to the Dixa Public API \(dev.dixa.io\) began failing with an error. The outage was caused by a faulty deployment of the component that authenticates incoming API requests. Our team detected the issue at 11:16 AM CEST, identified the cause, and deployed a fix. Full service was restored at 11:31 AM CEST. ## Impact Between 11:15 AM and 11:31 AM CEST, the Dixa Public API was unavailable for all customers. Every API request in this window, across all API versions, received an HTTP 500 error, and no request succeeded. Requests were rejected before they reached our systems, so no request was partially processed, and no data was lost or changed. Integrations that retry failed requests automatically will have recovered on their own. Integrations that do not retry may need to resend any calls made during this window. ## Root Cause The outage was caused by a manual deployment of the component that authenticates every request to the Dixa Public API. The new version of this component was packaged incorrectly, so it could not start. Without a working authentication step, every incoming API request failed. The code itself was correct; the problem was only in how it was packaged for deployment. ## Resolution Our team detected the issue at 11:16 AM CEST and began investigating the affected services. By 11:26 AM CEST, the root cause had been traced to the faulty deployment. A correctly packaged version of the same code was deployed at 11:30 AM CEST, and API requests began succeeding again immediately. Error rates were back to normal levels by 11:32 AM CEST. ## Preventive Measures To help prevent similar incidents going forward, we are: * Replacing manual deployments of this component with an automated deployment pipeline * Testing every change in a staging environment before it reaches production * Improving versioned releases, so we can roll back to a known-good version immediately * Adding further automated alerts on API authentication errors and error rates to detect issues faster ## Closing Note We understand how important reliable access to the Dixa Public API is to your integrations and workflows. We apologize for any inconvenience caused during this period and are committed to strengthening the resilience of this service.

Read the full incident report →

Started Jul 28, 2026, 10:47 AM UTC· resolved Jul 28, 2026, 11:15 AM UTC

1. investigating Jul 28, 2026, 10:47 AM UTC

   We are experiencing some difficulties with Advanced Insight & Miuros. We are investigating the matter. Next update at 13:30 CEST

2. resolved Jul 28, 2026, 11:15 AM UTC

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

3. postmortem Aug 05, 2026, 06:45 AM UTC

   ### **Post-Mortem: Advanced Insight & Miuros Degraded Performance** **Date of Incident:** July 28, 2026 **Duration:** 12:47 PM – 1:15 PM CEST \(28 minutes\) **Severity:** Medium — degraded performance, partial access issues #### **Summary** On July 28, 2026, at 12:47 PM CEST, users began experiencing degraded performance and intermittent difficulty accessing Advanced Insight & Miuros. Our team identified the issue and began investigating shortly after it was detected. A fix was implemented, and full service was confirmed restored by 1:15 PM CEST. #### **Impact** Between 12:47 PM and 1:15 PM CEST, some users experienced slow load times or were unable to reliably access Advanced Insight & Miuros. No data loss occurred, and access was fully restored once the fix was deployed. #### **Root Cause** The degraded performance was traced to a change introduced during a recent deployment to the Advanced Insight & Miuros environment, which had an unintended impact on service performance. Once flagged, our engineering team investigated the affected components and implemented a corrective fix to restore normal performance. #### **Resolution** Upon detecting the issue at 12:47 PM CEST, our team began investigating the affected services. The root cause was traced to the recent deployment, and a fix was rolled out, resolving the degraded performance. Full functionality was confirmed at 1:15 PM CEST. #### **Preventive Measures** To help prevent similar incidents going forward, we are: * Strengthening pre-deployment validation and performance testing for Advanced Insight & Miuros * Improving monitoring and alerting thresholds to detect performance degradation earlier * Refining our rollback process to reduce time-to-resolution for similar issues #### **Closing Note** We understand how important reliable access to Advanced Insight & Miuros is to your workflows. We apologize for any inconvenience caused during this period and are committed to strengthening the resilience of this service.

Read the full incident report →

Started Jul 28, 2026, 06:53 AM UTC· resolved Jul 28, 2026, 07:03 AM UTC

1. resolved Jul 28, 2026, 07:00 AM UTC

   At 8:53 AM CEST on 28/07/2026, our services for converastion handling and logging into Dixa were not fully functioning. Our engineers were immediately notified of the issue and started working on identifying the root cause. At 9:03 AM CEST, a fix for this issue was deployed, and the affected services were again fully functioning. We have performed a Root Cause Analysis of this incident and are implementing solutions in order to prevent such instances from happening in the future. We sincerely apologize for any inconvenience that this may have caused.

2. postmortem Aug 05, 2026, 06:43 AM UTC

   ### **Post-Mortem: Conversation Handling & Login Service Disruption** **Date of Incident:** July 28, 2026 **Duration:** 8:53 AM – 9:03 AM CEST \(10 minutes\) **Severity:** High — partial service disruption #### **Summary** On July 28, 2026, at 8:53 AM CEST, Dixa experienced a service disruption affecting conversation handling and user login functionality. The issue was identified quickly by our engineering team, a fix was deployed at 9:03 AM CEST, and full functionality was restored within 10 minutes of the initial impact. #### **Impact** Users may have experienced difficulty logging into Dixa or handling conversations during the affected window. No data loss occurred, and all systems returned to normal operation by 9:03 AM CEST. #### **Root Cause** The disruption was traced to a change introduced during a routine deployment to our production environment, which had an unintended effect on the services responsible for conversation handling and authentication. Our monitoring systems flagged the anomaly shortly after it occurred, allowing our engineering team to identify and roll back the change quickly. #### **Resolution** Engineers on-call were alerted immediately once the anomaly was detected. The team traced the issue to the recent deployment and deployed a corrective fix at 9:03 AM CEST, which resolved the disruption. #### **Preventive Measures** To reduce the likelihood of similar incidents going forward, we are: * Strengthening our pre-deployment validation checks to catch this class of issue before it reaches production * Improving automated rollback triggers so similar anomalies are reverted even faster * Enhancing monitoring coverage on conversation handling and authentication services specifically #### **Closing Note** We know reliability is critical to how you run your business, and we take incidents like this seriously. We apologize for any inconvenience this may have caused and remain committed to continuously improving the resilience of our platform.

Read the full incident report →

Started Jun 29, 2026, 09:04 AM UTC· resolved Jun 29, 2026, 03:11 PM UTC

1. investigating Jun 29, 2026, 09:04 AM UTC

   We are currently investigating an issue affecting access to Advanced Insights in Dixa. Some users may be unable to access this feature at this time. Our team is actively looking into the root cause and will provide an update as soon as more information is available. We apologize for the inconvenience.

2. investigating Jun 29, 2026, 09:08 AM UTC

   We are continuing to investigate this issue.

3. monitoring Jun 29, 2026, 09:30 AM UTC

   We have identified the issue affecting access to Advanced Insights and have implemented a fix. We are currently monitoring the situation to confirm full resolution. Please note that data from the past 3 hours may still be missing. We are working to recover this and will provide a further update once the issue is fully resolved. We apologize for the inconvenience.

4. monitoring Jun 29, 2026, 12:30 PM UTC

   We're still gradually re-deploying data so data may still be stale from this morning for some customers. We'll update this page when everything is up to date.

5. resolved Jun 29, 2026, 03:11 PM UTC

   All data is now re-deployed and we're completely up to date for everyone.

Read the full incident report →

Started Apr 23, 2026, 11:42 AM UTC· resolved Apr 23, 2026, 11:51 AM UTC

1. monitoring Apr 23, 2026, 11:42 AM UTC

   We're currently aware of an increased delay with data showing in the Conversation view and Real Time dashboard. Conversation offers are fully operational, but you might see conversations on the dashboard that have been offered already and/or outdated information on the Conversations view. We'll notify here when data ingestion has caught up.

2. resolved Apr 23, 2026, 11:51 AM UTC

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

Read the full incident report →

Started Apr 08, 2026, 04:32 PM UTC· resolved Apr 08, 2026, 05:24 PM UTC

1. investigating Apr 08, 2026, 04:32 PM UTC

   We've received reports of Dixa not loading. We're investigating and will come back to you with an update as soon as we know more. Next update at 16:45 UTC (18:45 CEST)

2. investigating Apr 08, 2026, 04:37 PM UTC

   We are continuing to investigate this issue.

3. investigating Apr 08, 2026, 04:50 PM UTC

   We're still trying to find the cause. We'll update you again in 15 minutes, or sooner if we have identified the problem.

4. identified Apr 08, 2026, 05:00 PM UTC

   We've identified the cause of the issue, and are actively working towards a solution. While we do so, we also confirmed that this only impacts connections towards the agent interface. Other parts of Dixa are not impacted by this partial outage. We'll report back at 17:15 UTC (19:15 CEST), or earlier as soon as we have more information to share.

5. monitoring Apr 08, 2026, 05:12 PM UTC

   We are happy to inform, that our teams have deployed a fix for the issue. We are seeing agents successfully reconnect to agent interface. We will continue to monitor the results. Next update at 17:30 UTC (19:30 CEST)

6. resolved Apr 08, 2026, 05:24 PM UTC

   This incident has now been resolved. Our sincere apologies for the disruption. We identified the cause of the issue being a configuration issue on a new entry point for agent connections towards agent interface that was introduced earlier today. More information will be shared in the post mortem, which will be posted here within 5 business days. If you have questions about today's outage, feel free to reach out to [email protected]. We'll be happy to help.

7. postmortem Apr 10, 2026, 12:21 PM UTC

   ## **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 [[email protected]](mailto:[email protected]).

Read the full incident report →

Started Mar 18, 2026, 03:02 PM UTC· resolved Mar 18, 2026, 07:52 PM UTC

1. investigating Mar 18, 2026, 03:02 PM UTC

   We are experiencing some difficulties with the AiCoPilot feature "Smart Replies". We are investigating the matter. Next update at 3:30 PM UTC

2. investigating Mar 18, 2026, 03:02 PM UTC

   We are continuing to investigate this issue.

3. investigating Mar 18, 2026, 03:48 PM UTC

   We are further investigating the matter. Thank you for your patience.

4. investigating Mar 18, 2026, 05:17 PM UTC

   Our engineering team is actively investigating the root cause. This might take some time to fully resolve and we will continue to provide updates here on daily basis. We apologize for any inconvenience caused and thank you for your patience.

5. resolved Mar 18, 2026, 07:52 PM UTC

   All known issues to this incident have been resolved. We thank you for your patience and cooperation. Post mortem about this incident will be posted within 5 business days.

6. postmortem Mar 26, 2026, 08:54 AM UTC

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

Read the full incident report →

Started Mar 11, 2026, 08:18 AM UTC· resolved Mar 11, 2026, 11:31 AM UTC

1. investigating Mar 11, 2026, 08:18 AM UTC

   We have received reports of instability in the platform. We are investigating the issue. Updates will follow

2. investigating Mar 11, 2026, 08:34 AM UTC

   We are receiving reports of slowness in the agent interface. We are investigating the issue. Next update at 09:50 CET

3. investigating Mar 11, 2026, 08:51 AM UTC

   We have received reports of instability in the platform. We are investigating the issue. Updates will follow

4. monitoring Mar 11, 2026, 08:54 AM UTC

   Our teams has now identified the issue. We are working on a fix, that will resolve the issue. We will provide more information soon. Next update at 10:10 CET

5. monitoring Mar 11, 2026, 09:14 AM UTC

   We are continuing to monitor system metrics and are observing a recovering trend. Next update: 10:30 CET

6. monitoring Mar 11, 2026, 09:31 AM UTC

   We continue to observe improvements. We can confirm there was no data loss. Please note that as a side effect, some conversations may have been routed to the default queue. We apologize for any inconvenience caused. Next update: 11:00 CET

7. identified Mar 11, 2026, 09:59 AM UTC

   We have identified some additional disruptions in the service. Our team is actively working on a fix. Next update: 11:30hs

8. identified Mar 11, 2026, 10:35 AM UTC

   We continue to actively work on resolving this incident with the highest priority. Our team remains fully engaged and further updates will follow as our investigation progresses. Next update: 12:00 hs

9. monitoring Mar 11, 2026, 10:54 AM UTC

   A fix has been deployed and we are observing improvements across system metrics. Our team will continue to actively monitor the situation until full recovery is confirmed. Next update: 12:30 CET

10. resolved Mar 11, 2026, 11:31 AM UTC

    All known issues linked to this incident have been fixed and full recovery of the platform has been confirmed. We thank you for your patience and cooperation. A postmortem will be published within 5 business days.

11. postmortem Mar 13, 2026, 12:22 PM UTC

    **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 [[email protected]](mailto:[email protected]).

Read the full incident report →

Started Mar 10, 2026, 12:38 PM UTC· resolved Mar 10, 2026, 05:03 PM UTC

1. investigating Mar 10, 2026, 12:38 PM UTC

   We are currently investigating an issue affecting the Help Center (Dixa Knowledge). We will provide a further update by 14:00 CET.

2. identified Mar 10, 2026, 12:57 PM UTC

   Our teams has now identified the issue. We are working on a fix, that will resolve the issue. We will provide more information soon. Next update at 14:10 CET

3. monitoring Mar 10, 2026, 01:13 PM UTC

   A fix has been deployed and we are seeing significant improvements to the Help Center (Dixa Knowledge). Some images and custom styling may still not display correctly yet. Our team is actively working to resolve this. Next update: 14:30 CET.

4. monitoring Mar 10, 2026, 01:48 PM UTC

   We are continuing to monitor the situation. While the Help Center (Dixa Knowledge) has largely recovered, some custom CSS styling issues remain. We will provide a further update shortly

5. resolved Mar 10, 2026, 05:03 PM UTC

   We can confirm that the issue has been resolved. A postmortem report will be published within 5 business days.

6. postmortem Mar 16, 2026, 05:02 PM UTC

   **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 [email protected].

Read the full incident report →

Started Mar 02, 2026, 06:08 PM UTC· resolved Mar 02, 2026, 08:21 PM UTC

1. investigating Mar 02, 2026, 06:08 PM UTC

   We have received reports of instability in the platform. We are investigating the issue. Updates will follow

2. investigating Mar 02, 2026, 06:16 PM UTC

   We've received reports of slowness and problems with responsiveness across Dixa's agent interface. We're investigating.

3. investigating Mar 02, 2026, 06:25 PM UTC

   We are continuing to investigate this issue.

4. investigating Mar 02, 2026, 06:45 PM UTC

   We are continuing to investigate this issue.

5. investigating Mar 02, 2026, 07:06 PM UTC

   We've taken a few measures trying to improve stability while we investigate the cause of the issues. You may notice slight improvement, but we haven't pinned down the root cause yet.

6. identified Mar 02, 2026, 07:18 PM UTC

   We've identified the cause of the issues and are taking measures to resolve the problems you're experiencing as soon as possible. Our sincere apologies for the inconvenience caused.

7. monitoring Mar 02, 2026, 08:09 PM UTC

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

8. resolved Mar 02, 2026, 08:21 PM UTC

   The incident has been resolved. During the incident, inbound emails may have had trouble processing. You may therefore experience some blank, queue-less emails that didn't properly go through a flow, followed by an inbound email that did go through your email flow and does have the correct message. You can safely close these conversations or merge them into the correctly processed inbound email. We sincerely apologize for the inconvenience and encourage you to contact [email protected] if you have further questions. A Post Mortem will be posted within 5 business days.

9. postmortem Mar 04, 2026, 03:21 PM UTC

   **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 [[email protected]](mailto:[email protected]).

Read the full incident report →

Started Feb 20, 2026, 02:24 PM UTC· resolved Feb 20, 2026, 02:35 PM UTC

1. investigating Feb 20, 2026, 02:24 PM UTC

   We have received reports of instability in the platform. We are investigating the issue. Updates will follow

2. resolved Feb 20, 2026, 02:35 PM UTC

   All known issues related to this incident have been resolved. We experienced a brief incident that caused slowness and intermittent timeouts across the platform. During this period, some customers may have experienced degraded performance when working in the interface. The issue was identified and resolved quickly, and the platform is now operating normally. We apologize for the inconvenience and appreciate your patience. A post-mortem about this incident will be posted within 5 business days.

3. postmortem Feb 25, 2026, 07:05 AM UTC

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

Read the full incident report →

Started Jan 27, 2026, 11:41 AM UTC· resolved Jan 27, 2026, 12:36 PM UTC

1. investigating Jan 27, 2026, 11:41 AM UTC

   We are experiencing some difficulties with AI Voice transcripts. We are investigating the matter. Next update at 13:00 CET

2. identified Jan 27, 2026, 12:10 PM UTC

   We have identified the issue as related to one of our providers. We continue to monitor the situation closely. Next update: 14:00 CET

3. resolved Jan 27, 2026, 12:36 PM UTC

   All known issues to this incident have been resolved by our partner. We thank you for your patience and cooperation. Post mortem about this incident will be posted within 5 business days.

4. postmortem Feb 02, 2026, 12:37 PM UTC

   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.

Read the full incident report →

Started Jan 06, 2026, 03:24 PM UTC· resolved Jan 06, 2026, 03:40 PM UTC

1. investigating Jan 06, 2026, 03:24 PM UTC

   We are experiencing some difficulties with searching for contacts when making outbound calls. We are investigating the matter. In the short term, we recommend pasting phone numbers in directly.

2. identified Jan 06, 2026, 03:32 PM UTC

   Our teams has now identified the issue. We are working on a fix, that will resolve the issue.

3. monitoring Jan 06, 2026, 03:35 PM UTC

   We are happy to inform, that our teams have deployed a fix for the issue. We will continue to monitor the results.

4. resolved Jan 06, 2026, 03:40 PM UTC

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

Read the full incident report →

Started Dec 22, 2025, 10:30 AM UTC· resolved Dec 22, 2025, 01:41 PM UTC

1. investigating Dec 22, 2025, 10:30 AM UTC

   We have received reports of instability in the platform. We are investigating the issue. Updates will follow

2. investigating Dec 22, 2025, 10:33 AM UTC

   We are continuing to investigate this issue.

3. identified Dec 22, 2025, 11:00 AM UTC

   We have identified the root cause of the issue and are working actively on implementing the fix. We will keep updating status page with the progress.

4. identified Dec 22, 2025, 11:26 AM UTC

   We are still working on a full resolution to this issue. Additionally, we currently experience a slight delay in certain webhooks events which will fully caught up once the issue is resolved.

5. identified Dec 22, 2025, 11:54 AM UTC

   The issue with AI Voice transcripts is now fully resolved. All missing transcripts were now created and the new ones are created as expected. We are still working on an issue with delays of some webhook events.

6. identified Dec 22, 2025, 12:47 PM UTC

   We are still experiencing delays in some webhook events, we will update the status page once this issue is resolved. We truly apologise for the inconvenience.

7. monitoring Dec 22, 2025, 12:59 PM UTC

   All issues related to this incident have been fixed. Webhooks events are being processed as expected. We will monitor the situation before we move the status to Resolved.

8. resolved Dec 22, 2025, 01:41 PM UTC

   This incident has been resolved. We will publish postmortem within five business days. We are truly sorry for the inconvenience.

9. postmortem Jan 13, 2026, 11:48 AM UTC

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

Read the full incident report →

Started Dec 16, 2025, 07:49 PM UTC· resolved Dec 16, 2025, 08:34 PM UTC

1. investigating Dec 16, 2025, 07:49 PM UTC

   We are observing challenges with loading Co-pilot features. We are working on identifying the root case and will update the status page as soon as the issue is identified.

2. investigating Dec 16, 2025, 07:55 PM UTC

   We are continuing to investigate this issue.

3. identified Dec 16, 2025, 08:03 PM UTC

   We have identified the root cause and applying the fix.

4. monitoring Dec 16, 2025, 08:12 PM UTC

   We deployed a fix and can see that the issue is resolved. We will monitor the situation for a some time now until we fully close the incident.

5. resolved Dec 16, 2025, 08:34 PM UTC

   This incident has been resolved. We will publish postmortem within 5 business days.

6. postmortem Dec 23, 2025, 03:44 PM UTC

   **Summary** On the 16th of December 2025 between 8:49 PM CET and 9:34 PM CET we experienced intermittent issues with AI features such as Co-pilot and intent detection automation on some of the Dixa instances. **Root cause** The incident was caused by the increased usage of the above mentioned features which caused hitting the set usage limit. **Timeline** At 8:49 PM CET: We started observing usage spikes which resulted in errors that started occurring around AI related features. At 8:55 PM CET: Status page was updated with the areas that were impacted by the issue. At 9:03 PM CET: We found the root cause and moved the incident status to Identified. At 9:12 PM CET: The fix was deployed and the incident status changed to Monitoring. At 9:34 PM CET: After a period of monitoring we did not observed any more errors and the incident status was moved to Resolved. **Solution** The immediate solution was to increase the usage limits as well as implement the separation of the limits per each AI feature in the backend. Long term we are planning to implement proactive alerting and monitoring around AI features usage and set limits to prevent the errors that occurred when the usage spiked. ‌ We sincerely apologise for the inconvenience caused by the above issue.

Read the full incident report →

Started Dec 08, 2025, 01:28 PM UTC· resolved Dec 08, 2025, 02:07 PM UTC

1. resolved Dec 08, 2025, 01:30 PM UTC

   Summary Parts of Dixa’s search functionality malfunctioned during a 30-minute window, following a deployment including some deficient code, affecting, amongst others, the search feature within the Email and Phone composer features, respectively. Root Cause Starting at 2.28 PM (CET) on 8 Dec, the faulty application started serving requests, some of which it was unable to handle. This was due to an insufficiently tested code path that got invoked under certain feature flag configurations, resulting in the search request not being handled correctly. Action Items On-call engineers were alerted about elevated error levels within 15 minutes of the first failing requests, and shortly after, were able to identify the impaired deployment, rolling it back to a previous version while investigations continued. At 3.07 PM (CET), error rates related to failing search requests had completely levelled off. A fix to the root issue has been released since, further improving the overall safety and handling of code dictated by feature flag configurations. This includes more thorough runtime parameter checks as well as adding several regression tests to ensure the issue won’t be reintroduced.

Read the full incident report →

Started Nov 18, 2025, 11:59 AM UTC· resolved Nov 18, 2025, 03:43 PM UTC

1. investigating Nov 18, 2025, 11:59 AM UTC

   We are experiencing some difficulties with Dixa Knowledge an AI Co-Pilot functionality. We are investigating the matter. Next update at 12.15 PM UTC

2. identified Nov 18, 2025, 12:06 PM UTC

   We've identified that the problems are caused by an outage at a third party, Cloudflare. Dixa only uses Cloudflare for Dixa Knowledge and is therefore largely unaffected. However, some of our sub-processors may also use Cloudflare for some or all of their services. Currently, we've identified that our AI-powered features are not, or only partially, working. We will keep you informed of any changes in the situation. Next update in half an hour.

3. identified Nov 18, 2025, 12:31 PM UTC

   We are seeing signs of improvement, and services are slowly recovering. Dixa Knowledge help centers appear to be intermittently available again. The outage is related to an ongoing issue with a third-party provider (Cloudflare). We will continue to monitor the situation and provide updates as full service is restored. We will update you again in 30 minutes.

4. identified Nov 18, 2025, 12:44 PM UTC

   We've identified that the problems are caused by an outage at a third party, Cloudflare. Dixa only uses Cloudflare for Dixa Knowledge and is therefore largely unaffected. However, some of our sub-processors may also use Cloudflare for some or all of their services. Currently, we've identified that our AI-powered features are not, or only partially, working. Dixa Knowledge Help Centers may also be throwing intermittent errors. We will keep you informed of any changes in the situation.

5. identified Nov 18, 2025, 01:02 PM UTC

   We are continuing to monitor service disruptions affecting our AI-related features due to ongoing issues with Cloudflare infrastructure. We have observed intermittent improvements in service availability and Dixa Knowledge KBs appear to be mostly working as of right now, though KB visitors may still experience intermittent issues. Cloudflare provides critical internet infrastructure for thousands of services worldwide. When they experience issues, it may have a serious impact on services that depend on their infrastructure. Our team is closely monitoring the situation alongside both Cloudflare and our AI subprocessor as they work toward resolution. We apologize for any inconvenience and will continue to provide updates as the situation develops.

6. identified Nov 18, 2025, 01:49 PM UTC

   Our AI sub-processor reports seeing a small number of requests being processed successfully with the majority still failing while Cloudflare continues to work on restoring their services. We continue to monitor both our AI provider as well as Cloudflare for any changes, and will update you here when there is more information to share. Thank you for your patience and our apologies once again for the disruptions you may be experiencing today.

7. monitoring Nov 18, 2025, 02:46 PM UTC

   The issues at Cloudflare appear to have been fully resolved. As a result, all related impact on Dixa services has also been mitigated. Dixa Knowledge and AI-powered features such as Co-Pilot, Mim, Intent detection and smart replies are now operating normally again. We will continue to monitor performance closely, but no further disruption is expected. Our sincere apologies for any inconvenience this may have caused.

8. monitoring Nov 18, 2025, 02:47 PM UTC

   The issues at Cloudflare appear to have been fully resolved. As a result, all related impact on Dixa services has also been mitigated. Dixa Knowledge and AI-powered features such as Co-Pilot, Mim, Intent detection and smart replies are now operating normally again. We will continue to monitor performance closely, but no further disruption is expected. Our sincere apologies for any inconvenience this may have caused.

9. resolved Nov 18, 2025, 03:43 PM UTC

   Although Cloudflare is still reporting problems, we are confident that the issues impacting Dixa services have been resolved. Dixa Knowledge Bases and AI-powered features have been fully operational as of 15:45 CET (14:45 UTC). A post-mortem will be posted within 5 days.

10. postmortem Nov 20, 2025, 08:20 AM UTC

    **Summary** On the 18th of November 2025 at 12:55 PM CET we received reports of Dixa Knowledge help centers not being available due to a Cloudflare error. At roughly the same time, we were made aware internally that we were receiving a lot of errors on AI-related functionality from one of our upstream sub-processors handling AI requests.‌ **Root cause** The incident originated from a major Cloudflare service disruption \([https://www.cloudflarestatus.com/incidents/8gmgl950y3h7\)](https://www.cloudflarestatus.com/incidents/8gmgl950y3h7)) caused by a configuration file used for Cloudflare’s Bot Management system. The file was auto-generated and due to a bug became too large, subsequently crashing Cloudflare services and causing major disruption across the globe. Dixa is using Cloudflare solely for the purpose of serving Dixa Knowledge's Knowledge Bases. Cloudflare helps us handle verification of custom host names and generating certificates for these custom host names, as well as protect the knowledge bases from malicious third parties. We quickly learned that one of our upstream sub-processors for AI-related features also uses Cloudflare for similar reasons, therefore also breaking AI Co-Pilot, Mim, Intent Detection and other AI-powered features inside Dixa. **Timeline** At 12:55 pm CET: We started observing increased errors on services handling AI-related features inside Dixa and received the first report about Dixa Knowledge KBs being inaccessible. We triggered our internal incident process and communicated here at 12:59 PM CET. At 1:06 pm CET: The full impact on Dixa services started to become clear, and we were confident only AI-related features and Knowledge Bases were affected. For the next hour and a half, we monitored the situation closely and saw alternating service recovery and disruption on the before-mentioned services while Cloudflare was recovering. At 2:49 pm CET: We were made aware by our AI sub-processor that they saw slight improvements in connectivity. At 3:46 pm CET: The impacted systems have fully recovered. The incident status was moved to Monitoring. At 5.43 pm CET: We changed the incident on our status page from 'Monitoring' to 'Resolved' as no further problems have been reported nor detected. At 6:44 pm CET: Cloudflare confirmed that the incident is fully resolved on their end. ‌ We sincerely apologize for the inconvenience this has caused.

Read the full incident report →

Started Oct 20, 2025, 04:55 PM UTC· resolved Oct 20, 2025, 10:56 PM UTC

1. identified Oct 20, 2025, 04:55 PM UTC

   We continue seeing interruptions with the telephony service. Inbound and outbound traffic on some numbers might be affected. The issue is caused by the problem with Amazon AWS services (https://health.aws.amazon.com/health/status) and services affected by it like Twilio (https://status.twilio.com/). We will keep monitoring status of the issues and adding updates to the status page. We will publish the next update in 60 minutes.

2. identified Oct 20, 2025, 05:52 PM UTC

   Some customers might still experience intermittent issues with inbound and outbound calls as an upstream incident causing these issues is not fully resolved. We will keep updating the status of this issue within the next 60 minutes.

3. identified Oct 20, 2025, 06:51 PM UTC

   The telephony inbound and outbound traffic looks stable at the moment, however the main AWS incident causing this issue is still not fully resolved therefore temporary and intermittent issues might be expected. We will post the next update within 60 minutes.

4. monitoring Oct 20, 2025, 07:46 PM UTC

   The services at AWS and Twilio that caused the telephony inbound and outbound intermittent issues have been mostly recovered. We do not see signs of issues on our service. We are moving the incident to Monitoring status.

5. resolved Oct 20, 2025, 10:56 PM UTC

   The issue is now fully resolved.

6. postmortem Oct 28, 2025, 03:46 PM UTC

   **Summary** On the 20th of October 2025 at 6:55 PM CEST due to the ongoing AWS incident Dixa experienced intermittent issues with Telephony Inbound and Outbound connectivity. On some Dixa instances the calls were not being placed or the connection between agents and users was not established. ‌ **Root cause** The incident originated from a **major AWS service disruption in the us-east-1 region** caused by a **DNS race condition within Amazon DynamoDB’s endpoint management system**. The fault temporarily removed valid DNS records for several AWS services, resulting in widespread API resolution failures across multiple dependent systems. Dixa is using Twilio’s APIs for **telephony services.** When DynamoDB’s DNS records were invalidated, Twilio’s **regional load balancers lost access to key internal routing data**, which caused inbound and outbound voice requests to fail. Because Twilio’s APIs are globally routed through Twilio’s us-east-1 infrastructure, Dixa’s platform became unable to establish or maintain voice sessions. ‌ **Timeline** At 06:55 pm CEST: We started observing intermittent interruptions with Telephony Inbound and Outbound service. Only some Dixa instances and phone numbers were affected. The incident was reported with the Identified status. At 07:52 pm CEST: The update is posted stating that some of the services are still impacted. At 08:51 pm CEST: There are no signs of issues on Dixa services anymore, however the third party services are still recovering and minimal interruptions could be expected. At 09:46 pm CEST: The impacted systems have fully recovered. The incident status was moved to Monitoring. At 00:56 am CEST on the 21st of October: AWS confirmed that the incident is fully resolved on their end. Dixa’s incident status was changed to Resolved. ‌ **Preventive measures** Dixa will evaluate implementing the following measures to mitigate the risk of similar issues in the future: * evaluate the feasibility of enabling outbound and inbound routing via multi-regional providers in case the us-east-1 Twilio region fails. * Independent external health check monitoring outside of AWS and Twilio. * Service dependency mapping and redundancy revisit. * Incident communication redundancy ‌ We sincerely apologise for the inconvenience this has caused.

Read the full incident report →

Started Oct 20, 2025, 07:16 AM UTC· resolved Oct 20, 2025, 01:19 PM UTC

1. investigating Oct 20, 2025, 07:16 AM UTC

   We have received reports of instability in the platform. We are investigating the issue. Updates will follow

2. identified Oct 20, 2025, 08:07 AM UTC

   We are currently experiencing significant issues with our telephony channel, which is impacting our ability to provide telephony services to our customers. Both inbound and outbound traffic are being affected, meaning that you will encounter difficulties when trying to make or receive calls. Additionally, our SMS and Whatsapp channels may also experience disruptions as a result of this ongoing issue, which could hinder your ability to communicate via those platforms as well. The root cause of these problems is related to an incident with our telephony services provider, which is completely outside of our control. We want to assure you that we are actively collaborating with them to address and resolve the issue at the earliest possible opportunity. Our team is working diligently to ensure that normal service is restored as quickly as possible. We believe that the current issues are likely tied to a larger incident that a major cloud service provider is experiencing in one of its regions. This situation has unfortunately impacted multiple services, including ours, complicating the process further. We sincerely apologize for any inconvenience this may cause you and appreciate your patience and understanding during this time. Our priority is to keep you updated as we work through this situation, and we are committed to restoring service as swiftly as possible.

3. identified Oct 20, 2025, 08:20 AM UTC

   We are currently experiencing significant issues with our telephony channel, which is impacting our ability to provide telephony services to our customers. Both inbound and outbound traffic are being affected, meaning that you will encounter difficulties when trying to make or receive calls. Additionally, our SMS and Whatsapp channels may also experience disruptions as a result of this ongoing issue, which could hinder your ability to communicate via those platforms as well. The root cause of these problems is related to an incident with our telephony services provider, which is completely outside of our control. We want to assure you that we are actively collaborating with them to address and resolve the issue at the earliest possible opportunity. Our team is working diligently to ensure that normal service is restored as quickly as possible. We believe that the current issues are likely tied to a larger incident that a major cloud service provider is experiencing in one of its regions. This situation has unfortunately impacted multiple services, including ours, complicating the process further. We sincerely apologize for any inconvenience this may cause you and appreciate your patience and understanding during this time. Our priority is to keep you updated as we work through this situation, and we are committed to restoring service as swiftly as possible

4. identified Oct 20, 2025, 08:55 AM UTC

   The issues are still continuing and telephony is still down. We're following the issue which is related to an outage for our telephony network supplier Twilio (https://status.twilio.com/). This in turn is caused by an Incident at AWS (https://health.aws.amazon.com/health/status). As a consequence, other services dependent on AWS might experience downtime, such as Elevio and JIRA. We'll keep monitoring and will keep you posted once we get an update. Next update is at latest in one hour

5. identified Oct 20, 2025, 09:52 AM UTC

   We can see that log in issues to Elevio and Jira (including the Jira integration) are now resolved, however we are still experiencing issues with the telephony channel due to the outage at Twilio (https://status.twilio.com/). We will keep updating the status of this incident, in one hour at the latest.

6. identified Oct 20, 2025, 10:38 AM UTC

   Telephony traffic is slowly recovering. The inbound calls are entering the Dixa platform and agents can accept offers but can't connect to the call. Outbound calls are still affected. We continue to follow the status of this issue with Twilio and we will keep posting updates. We will post the next update in 30 minutes.

7. identified Oct 20, 2025, 11:05 AM UTC

   We continue to see connection issues with phone calls. Calls are getting through to the Dixa platform but when agents accept the call, agents are not being connected to customers due to Twilio's network services which are still experiencing issues. SMS is fully functional again. We continue to monitor the situation and will update you again in the next 30 minutes, or sooner if there is news to share.

8. identified Oct 20, 2025, 11:26 AM UTC

   We are happy to report inbound and outbound calls are operational again. If agents continue to experience problems, ask them to refresh the page before trying again. We continue to monitor the situation up close, and if anything changes we will inform you via this page. If you continue to experience issues, feel free to reach out to Dixa support. Our sincere apologies for the inconvenience you are experiencing today. Next update in 60 minutes, or earlier if there is an update to share.

9. monitoring Oct 20, 2025, 12:21 PM UTC

   We're happy to report that all Whatsapp issues have been resolved, and messages sent out during the outage have caught up and have been sent to their receivers. We also got confirmation that telephony is working as expected. Again our sincere apologies for the inconvenience this has caused. If you still experience issues, please reach out to Dixa Support. We will continue to monitor if anything changes, but don't expect any further impact.

10. resolved Oct 20, 2025, 01:19 PM UTC

    All known issues reported as part of this incident have been fully resolved. We have been monitoring the system and all services are operational. We truly apologise for the inconvenience this incident cause and thank you for your patience while this was being solved. Post mortem about this incident will be posted within 5 business days.

11. postmortem Oct 28, 2025, 02:03 PM UTC

    **Summary** On the 20th of October 2025, starting from 08:58 am CEST, Dixa experienced widespread disruptions caused by the issues coming from third-party services. **Impacted services** * Telephony Inbound and Outbound traffic - Calls were not being placed for the most part of the incident, and for a period of time, calls were placed, but the connection between agents and end users was not established. * WhatsApp channel - conversations were queued but not sent during the incident. All queued messages were sent as soon as the issue was resolved. * SMS channel - conversations were queued but not sent during the incident. All queued messages were sent as soon as the issue was resolved. * Login to Elevio - login to Elevio was impacted. Help Centers were fully operational. * Login to the Status page was impacted, which caused challenges with communicating incident updates once the incident was raised. * Access to Dixa’s Public API documentation[ docs.dixa.io](http://docs.dixa.io) was also affected by the incident; Dixa’s API was fully operational. **Root cause** The incident originated from a **major AWS service disruption in the us-east-1 region** caused by a **DNS race condition within Amazon DynamoDB’s endpoint management system**. The fault temporarily removed valid DNS records for several AWS services, resulting in widespread API resolution failures across multiple dependent systems. Dixa is using Twilio’s APIs for **telephony, WhatsApp, and SMS channels**. When DynamoDB’s DNS records were invalidated, Twilio’s **regional load balancers lost access to key internal routing data**, which caused inbound and outbound voice requests to fail. This also impacted dependent APIs for SMS and WhatsApp delivery. Because Twilio’s APIs are globally routed through Twilio’s us-east-1 infrastructure, Dixa’s platform became unable to establish or maintain voice sessions, send or receive SMS messages, or process WhatsApp traffic. Other parts of the Dixa platform \(login, chat, email\) remained operational, but all Twilio-dependent communication channels were impacted for the most part of the duration of the AWS event. ### **Timeline** At 08:58 am CEST: We started observing errors in the logs coming from 3rd party systems, and shortly after, we started getting reports from customers about issues. At 09:16 am CEST: The Incident was reported on the status page with status: Investigating. The system we use for the status page was also impacted due to the same root cause at AWS, and we were unable to add further details regarding the incident. Between 9:00 and 10:00 am CEST: We kept updating the users who reached out to our support team about the status of the issue, while adding more details to the status page was not possible. At 10:00 am CEST: An updated incident message was posted in the Agent interface to notify users about the status of the incident At 10:07 am CEST: We regained access to the status page and updated the status of the incident to: Identified and added the information about impacted services. At 10:20 am CEST: The incident status update is posted as well, with the notification being sent to all status page subscribers. At 10:55 am CEST: The next status page update is posted with reference to the incidents at AWS and Twilio, which were the root cause of the issues with Dixa services. We also reported issues with logging in to Elevio caused by the same incident. At 11:52 am CEST: Update is posted. The Elevio login issue is resolved. The issue with telephony inbound and outbound, as well as SMS and WhatsApp service, continues. At 12:58 pm CEST: The first calls were starting to get to Dixa infrastructure again, but the voice in the calls was still not operational. At 13:05 pm CEST: The connection issue with telephony continues. SMS is confirmed to be fully operational again. At 13:26 pm CEST: The inbound and outbound telephony is confirmed to be operational again. At 14:21 pm CEST: WhatsApp is confirmed to be operational as well. All messages that were queued during the incident got successfully delivered. The incident status is changed to: Monitoring At 15:19 pm CEST: All systems have been operational since the incident was moved to Monitoring, and the incident status was changed to: Resolved. ‌ **Preventive measures** Dixa will evaluate implementing the following measures to mitigate the risk of similar issues in the future: * evaluate the feasibility of enabling outbound and inbound routing via multi-regional providers in case the us-east-1 Twilio region fails. * Independent external health check monitoring outside of AWS and Twilio. * Service dependency mapping and redundancy revisit. * Incident communication redundancy ‌ We sincerely apologise for the inconvenience this has caused.

Read the full incident report →

Started Oct 14, 2025, 08:24 AM UTC· resolved Oct 14, 2025, 12:41 PM UTC

1. investigating Oct 14, 2025, 08:24 AM UTC

   We are experiencing some difficulties with translations for AI Co-pilot. We are investigating the matter.

2. identified Oct 14, 2025, 08:37 AM UTC

   Our teams has now identified the issue and have deployed a fix. We're seeing progress and are monitoring.

3. identified Oct 14, 2025, 10:25 AM UTC

   We're still experiencing instabilities relating to AI Co-pilot features and we're working on a fix for it

4. monitoring Oct 14, 2025, 10:54 AM UTC

   A new fix has been deployed and we're seeing improvements. Please refresh the website and it should be back to normal. We're monitoring the progress

5. resolved Oct 14, 2025, 12:41 PM UTC

   All known issues to this incident have been resolved. We thank you for your patience and cooperation. Post mortem about this incident will be posted within 5 business days.

6. postmortem Oct 17, 2025, 11:56 AM UTC

   ### Summary Dixa experienced partial degraded performance of AI-Co pilot features on October 14 2025 between 08:13-13:13 CEST. Users who never changed their translation settings were affected, experiencing unwanted auto-translations and non working translations. The issues were cause by an increased number of translation requests hitting our api, leading to overload. We eventually solved it by increasing the capacity for handing requests and by reverting the changes **Timeline** At 08:13 am CEST A change was deployed for AI copilot to default the Auto summary and translations to “Automatic” for users who never changed their preferences At 09:48 am CEST First reports of difficulties with translations for AI Co-pilot that didn’t work at all. At 10:23 am CEST A fix is deployed to support the increased amount of requests incoming. At 10:33 am CEST Fix is evaluated to have mitigated the issues. At 11:33 CEST The requests to our API increase and issues come back, more reports are coming in from customers about conversations being automatically translated or translations not working at all. At ~12:45 am CEST Fix is applied to support even more increased amount of requests to prevent translation failures and the quota on the model used by translation is increased to support the increased amount of requests. At 13:13 am CEST A final fix is deployed - changes to AI copilot settings defaults are reverted and requires agents to reload to take effect. This decreased the system overload. ### **Impact** The incident had a major impact on the users of the AI Co-pilot feature that never changed their settings who experienced degraded performance with conversations not translating or unwanted increased amount of translations performed. ## **Root cause** The frontend changes to settings defaults for AI auto summary and translate flipped the settings from on-demand to automatic. It was applied to existing customers that never changed their settings. It appeared to be a significant amount of customers who had not done any changes to their settings. The change took effect over the course of multiple hours, because it required agents to reload the UI for the settings to take effect. This caused many more translations being performed where customers did not expect. Additionally, this caused increased amount of translation requests via rest-api, which made rest-api incapable of performing all requests due to it having a capped number on max open requests ### **Resolution** * Support for and quota of translation requests were increased * The frontend change to settings defaults for AI Co-pilot were reverted We have taken steps to improve our processes for control and increased the capacity limit so that this won’t happen again. We apologize for the inconvenience this caused and thank you for you cooperation

Read the full incident report →

Started Sep 09, 2025, 01:45 PM UTC· resolved Sep 09, 2025, 03:49 PM UTC

1. identified Sep 09, 2025, 01:45 PM UTC

   We are experiencing some difficulties with Analytics data being delayed, which affects the Analytics and Real-time Dashboard modules. We have identified and fixed the issue, so the data ingestion is catching up quickly.

2. monitoring Sep 09, 2025, 01:52 PM UTC

   All data has now caught up, and we'll continue to monitor the service closely

3. resolved Sep 09, 2025, 03:49 PM UTC

   All known issues to this incident have been resolved. We thank you for your patience and cooperation. Post mortem about this incident will be posted within 5 business days.

4. postmortem Sep 15, 2025, 06:29 AM UTC

   ## Summary On the 9th of September, 2025, a deployment at 2:45 PM CEST caused an ingestion delay affecting the Intelligence and the Realtime Dashboards. The incident was detected at 2:47 PM CEST by internal alerts as well as reports coming in to our Customer Support. A fix was released at 3:25 PM CEST, and all data was caught up at 3:51 PM CEST. The total incident was 66 minutes, with an impact on customers relying on our real-time dashboard and Intelligence module. ## Timeline * **2:45 PM CEST** - Deployment released that caused the incident where ingestion of data to Intelligence- and the Realtime Dashboards was delayed * **2:47 PM CEST** - Internal alerts notified relevant stakeholders at Dixa around the incident, and a fix was worked on * **3:25 PM CEST** - A fix was released, and delayed data started catching up * **3:51 PM CEST** - All delayed data had caught up **Total Duration:** 66 minutes ## Root Cause The incident was caused by a deployment that resulted in a delay in the ingestion of data. ## Impact * Realtime Dashboards * Intelligence/Analytics ## Resolution **Immediate Resolution:** * The engineering team started working on a fix as soon as internal alarms notified relevant stakeholders * Service functionality was restored following the fix, and the delayed data started catching up **Prevention Measures:** * Expand test coverage

Read the full incident report →

Started Aug 26, 2025, 02:30 PM UTC· resolved Aug 28, 2025, 06:52 AM UTC

1. investigating Aug 26, 2025, 02:30 PM UTC

   We are currently experiencing issues with new Mim synchronizations to data sources. While all previously synchronized data remains accessible and functional, new sync operations are failing to complete successfully. IMPACT: New Mim sync operations created since August 22 are failing Existing synchronized data continues to work normally Automatic syncs are not updating with new content Manual re-sync operations may disrupt existing working connections STATUS: Our engineering team is actively investigating the root cause of this issue. We strongly advise against initiating manual re-syncs at this time, as this may interrupt existing functional data connections.

2. identified Aug 27, 2025, 09:06 AM UTC

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

3. monitoring Aug 27, 2025, 04:08 PM UTC

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

4. resolved Aug 28, 2025, 06:52 AM UTC

   The incident has been fully resolved, and all services are operating normally. We sincerely apologize for the disruption and any impact this may have had on your operations. We appreciate your patience during this time.

5. postmortem Aug 28, 2025, 01:11 PM UTC

   **Date**: August 22, 2025 **Duration**: 5 days \(August 22-27, 2025\) **Severity**: Degraded ## Summary Between August 22-27, 2025, our AI assistant \(Mim\) experienced degraded response quality due to inconsistent knowledge base indexing failures. The incident was caused by our OpenSearch cluster rejecting document index requests due to memory constraints from oversized embeddings. While Mim continued to operate with partial knowledge data, customers experienced reduced response accuracy for 5 days until the issue was resolved through cluster scaling. ## Timeline * **August 22, 2025:** First indexing failures begin occurring * **August 22-25, 2025:** Indexing failures continue to grow in frequency * **August 25, 2025:** Issue escalated by CS team * **August 27, 2025 - 18:00 CEST:** Indexing failures stop occurring, and new knowledge bases can be indexed successfully * **August 28, 2025:** re-indexed existing Dixa Knowledge and elevio data sources * **August 28, 2025 - 12:00:** Full service restoration achieved ## Root Cause The system was unable to process knowledge base indexing requests due to insufficient computational resources relative to the data volume and complexity. Contributing factors included: * Inadequate system capacity for the current workload demands * Inefficient resource utilization patterns * Suboptimal data processing architecture that doesn't scale effectively with growth * Large data structures requiring more system resources than available ## Impact * **Duration**: 5 days \(August 22-27, 2025\) * **Service Level**: Degraded \(not complete outage\) * **User Experience**: Mim responses had reduced accuracy and completeness due to operating with partial knowledge data ## Resolution ### Immediate Actions Taken 1. **System Cleanup**: Removed unused data and optimized storage utilization 2. **Capacity Scaling**: Increased available computational resources to handle workload demands 3. **Performance Optimization**: Balanced system performance improvements with operational efficiency ### Long-term Improvements Planned 1. **Architecture Enhancement**: * Redesign data processing workflows for improved scalability * Implement more efficient system resource management 2. **Data Optimization**: * Evaluate opportunities to reduce data processing overhead * Optimize data formats for better system performance 3. **Monitoring Enhancement**: * Implement proactive alerting for system capacity issues * Add performance monitoring to prevent resource bottlenecks

Read the full incident report →

Started Aug 26, 2025, 12:20 PM UTC· resolved Aug 26, 2025, 12:45 PM UTC

1. resolved Aug 26, 2025, 12:20 PM UTC

   DNS records for dev.dixa.io were inadvertently removed. This resulted in DNS resolution failures when attempting to connect to dev.dixa.io, as requests received "NXDOMAIN" responses indicating no available IP address. This issue affected all services and integrations relying on our public API, including: Native integrations Custom cards Integration nodes in flows and automations Third-party services (Zapier, chatbots, etc.) All external API connections All affected services experienced connection failures during this period. The issue was resolved by restoring the proper DNS configuration for dev.dixa.io.

2. postmortem Aug 26, 2025, 01:28 PM UTC

   **Date:** August 26, 2025 **Duration:** 25 minutes \(14:20 - 14:45 CEST\) **Severity:** High - Complete API unavailability ## Summary A DNS configuration error during staging environment setup caused a complete outage of our public API at [dev.dixa.io](http://dev.dixa.io) for 25 minutes. All external integrations and services dependent on our API were affected. ## Timeline * **14:20 CEST** - DNS records for [dev.dixa.io](http://dev.dixa.io) inadvertently deleted during staging setup * **14:20 CEST** - API connectivity issues began affecting all external services * **14:45 CEST** - DNS configuration restored, services resumed normal operation ## Root Cause During the setup of staging DNS entries for [euw1.dev.dixa.io](http://euw1.dev.dixa.io), the existing DNS records for [dev.dixa.io](http://dev.dixa.io) were accidentally removed instead of being preserved alongside the new staging records. This caused all DNS queries for [dev.dixa.io](http://dev.dixa.io) to return NXDOMAIN responses. ## Impact * **Duration:** 25 minutes of complete API unavailability * **Affected Services:** All external integrations including native integrations, custom cards, flow automations, Zapier, chatbots, and third-party API consumers * **User Impact:** Complete inability to access API-dependent functionality ## Resolution The DNS configuration was corrected by restoring the proper DNS records for [dev.dixa.io](http://dev.dixa.io), immediately resolving the connectivity issues.

Read the full incident report →

Started Aug 26, 2025, 08:58 AM UTC· resolved Aug 26, 2025, 09:52 AM UTC

1. investigating Aug 26, 2025, 08:58 AM UTC

   We are currently investigating an issue with Trustpilot conversations not being offered to agents

2. monitoring Aug 26, 2025, 09:32 AM UTC

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

3. resolved Aug 26, 2025, 09:52 AM UTC

   This incident has been resolved.

4. postmortem Aug 27, 2025, 10:26 AM UTC

   ## Summary On August 26, 2025, a deployment at 10:32 AM CEST caused a complete outage of the TrustPilot queue service, preventing agents from opening TrustPilot conversations in the agent interface. The incident was detected by Customer Support 20 minutes after deployment and resolved through a rollback at 11:30 AM CEST. Total downtime was 58 minutes, with a high impact on TrustPilot customer service operations. ## Timeline * **10:32 CEST** - Image deployment initiated * **10:52 CEST** - Customer Support \(CS\) identified the TrustPilot queue service outage and notified the engineering team * **11:30 CEST** - Changes rolled back, service restored **Total Duration:** 58 minutes ## Root Cause The incident was caused by a deployment that contained changes incompatible with the TrustPilot queue service functionality. ## Impact * TrustPilot Conversations could not be opened in the agent interface * Complete disruption of TrustPilot queue operations * Agent workflow interruption for TrustPilot-related customer inquiries ## Resolution **Immediate Resolution:** * The engineering team executed a rollback of the deployed changes at 11:30 AM CEST * Service functionality was restored following the rollback * TrustPilot queue operations returned to normal **Prevention Measures:** * Expand integration test coverage for all third-party services * Implement automated health checks and alerting for critical service dependencies

Read the full incident report →