Dixa Outage History

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, 08:18 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 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:30 PM UTC· resolved Dec 08, 2025, 01:30 PM UTC

1. resolved Dec 11, 2025, 06:52 AM 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 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, 01:23 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 →

Started Jul 08, 2025, 08:41 AM UTC· resolved Jul 08, 2025, 09:22 AM UTC

1. investigating Jul 08, 2025, 08:41 AM UTC

   We've noticed that some of the articles are not loading on Dixa Knowledge base. We are investigating the issue.

2. identified Jul 08, 2025, 08:54 AM UTC

   The issue has been identified and we are working on implementing the fix.

3. monitoring Jul 08, 2025, 08:58 AM UTC

   The fix has been implemented and the articles are loading as expected.

4. resolved Jul 08, 2025, 09:22 AM UTC

   The issue has been resolved.

5. postmortem Jul 17, 2025, 02:52 PM UTC

   On the 8 of July 2025 at 10:41 am CEST we noticed the issue with some articles not loading on Dixa Knowledge. The users were getting redirected to a main page instead. This issue was caused by a faulty deployment which was reverted immediately and 10:58 am we moved the incident to monitoring. We could see that the articles are loading as intended and therefore considered the incident fully resolved at 11:22 CEST.

Read the full incident report →

Started Jul 01, 2025, 09:01 AM UTC· resolved Jul 01, 2025, 09:15 AM UTC

1. investigating Jul 01, 2025, 09:01 AM UTC

   We are currently investigating an issue with loading conversations.

2. monitoring Jul 01, 2025, 09:04 AM UTC

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

3. resolved Jul 01, 2025, 09:15 AM UTC

   This incident has been resolved.

4. postmortem Jul 04, 2025, 08:34 AM UTC

   **Incident Date:** July 1, 2025 **Incident Duration:** 10:49–11:15 AM UTC **Severity:** Major **Status:** Resolved ## Summary On the morning of July 1st, an infrastructure change aimed at improving the scalability of one of our core backend components caused a temporary disruption to key services, including the loading of conversations and analytics for several customers. ## Impact Between **10:49 AM and 11:01 AM UTC**, users experienced degraded service, including: * Inability to load Conversations and Analytics * Increased API latency and error rates * Service instability across core business functionalities The issue was identified quickly, and a rollback restored full functionality within 12 minutes. ## Timeline of Events | Time \(UTC\) | Event | | --- | --- | | **10:49 AM** | A change was deployed to our core. | | **10:53 AM** | Analytics service loading issues were reported. | | **10:54 AM** | Multiple customers reported that Conversations were not loading. | | **10:56 AM** | Engineers decided to roll back the change to the previous configuration. | | **11:01 AM** | Rollback completed. Services began functioning normally. | | **11:15 AM** | Incident was marked as resolved. API performance confirmed stable. | ## Immediate Fix The engineering team initiated a **rollback** to the previous provisioned capacity mode, restoring the prior configuration for both the table and its index. This resolved the throttling within minutes. ## Long-Term Preventive Actions To prevent similar incidents in the future, we are improving how configuration changes are tested and deployed: * **Improved Change Validation**: We’re enhancing our testing processes to better simulate real-world usage before changes are rolled out to production. * **Stronger Safeguards on Infrastructure Changes**: We’re updating how critical infrastructure components are configured to ensure changes do not unintentionally impact system performance. These improvements are part of our ongoing commitment to delivering a stable and reliable experience. ## Closing Notes We sincerely apologize for the disruption this caused. The lessons from this incident are already being acted on to further strengthen our systems and processes. Ensuring the reliability and scalability of our platform remains a top priority. If you have any questions or would like more details, please don’t hesitate to reach out to our support team.

Read the full incident report →

Started Jun 12, 2025, 12:29 PM UTC· resolved Jun 13, 2025, 04:30 PM UTC

1. investigating Jun 12, 2025, 12:29 PM UTC

   We are experiencing some difficulties with Search. We are investigating the matter. Next update at 15:30hs

2. identified Jun 12, 2025, 01:01 PM UTC

   Our teams has now identified the issue. We are working on a fix that will resolve the issue. Next update at 16:00 hs CEST

3. identified Jun 12, 2025, 02:37 PM UTC

   We are continuing to work on fixing this issue. We are sorry for any inconvenience this may cause

4. monitoring Jun 12, 2025, 08:18 PM UTC

   We are continuing to see stability across our platform. We will continue monitoring.

5. monitoring Jun 13, 2025, 08:01 AM UTC

   While we continue working on a permanent fix for this issue, we've temporarily reverted our search functionality back to an earlier version. This means filters for custom attributes and searching contacts based on external ID might not work as expected for the time being. You should still be able to find custom attribute values by directly searching for the values without using a filter. We'll update our status page when we have more news to share.

6. monitoring Jun 13, 2025, 01:32 PM UTC

   We continue to actively work on restoring Search. Some users may still experience some degraded performance. We are continuing to monitor the situation closely. We'll update our status page when we have more news.

7. resolved Jun 15, 2025, 09:14 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.

8. postmortem Jun 19, 2025, 01:16 PM UTC

   On the 12 of June 2025, we started observing stability issues with the new Search cluster, at the time of the incident, powering the Conversations & Contacts tabs on the Search page, as well as the Search POST endpoint of the Dixa API. Search results on the mentioned pages/endpoints were, to some degree, not updated in real time. The immediate solution was to scale up the cluster to better distribute the workloads, where the longer-term solution is to optimize affected workloads. We sincerely apologise for any inconvenience that this may have caused.

Read the full incident report →

Started May 31, 2025, 01:28 PM UTC· resolved May 31, 2025, 05:13 PM UTC

1. investigating May 31, 2025, 01:28 PM UTC

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

2. investigating May 31, 2025, 01:33 PM UTC

   We are experiencing some difficulties with Search functionality, for searching in conversations. We are investigating the matter.

3. investigating May 31, 2025, 03:35 PM UTC

   We are continuing to investigate this.

4. monitoring May 31, 2025, 03:38 PM UTC

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

5. resolved May 31, 2025, 05:13 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 May 27, 2025, 02:09 PM UTC· resolved May 27, 2025, 06:09 PM UTC

1. investigating May 27, 2025, 02:09 PM UTC

   One of our providers is currently experiencing an outage that affects the enablement of certain features. Some users might experience missing features; we are closely working with them to restore the services.

2. identified May 27, 2025, 02:29 PM UTC

   We’re still receiving updates from our provider and monitoring the situation. This issue likely doesn’t affect all customers, as some default flag values may match their previous configurations. We’ll provide further updates as we learn more.

3. monitoring May 27, 2025, 02:47 PM UTC

   We are happy to inform that our provider has deployed a fix for the issue. We will continue to monitor the results.

4. resolved May 27, 2025, 06:09 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 Apr 25, 2025, 07:18 AM UTC· resolved Apr 25, 2025, 08:51 AM UTC

1. investigating Apr 25, 2025, 07:18 AM UTC

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

2. investigating Apr 25, 2025, 07:23 AM UTC

   We're currently experiencing issues with searching for contacts. This also affects sending outbound emails, merging contacts and transferring conversations. Next update in 15 minutes.

3. monitoring Apr 25, 2025, 07:31 AM UTC

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

4. monitoring Apr 25, 2025, 07:32 AM UTC

   We are continuing to monitor for any further issues.

5. resolved Apr 25, 2025, 08:51 AM UTC

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

6. postmortem May 01, 2025, 05:32 AM UTC

   On April 25th, 2025, at 09:18 am CEST, a number of our customers experienced issues with sending outbound emails and searching for contacts due to a faulty update release. The issue was resolved at 09:27 am CEST. The immediate solution of rolling back the release and restarting the affected server led to the resolution of this issue. We 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 apologise for any inconvenience that this may have caused.

Read the full incident report →