Dstny incident

Intermittent Call Failures – ConnectMe, Nordics + EU

Resolved after 3 days 3 hours, affecting EU, on October 2, 2026.

postmortem Oct 15, 2026, 09:23 AM UTC

**Incident Summary** ConnectMe users experienced two separate periods of disruption. In the Nordics region, from 10:28 UTC on 1st October until 16:21 UTC on 2nd October 2026, a subset of users were unable to make or receive calls. A similar issue affected a subset of users in the EU West region from 08:22 UTC until 19:00 UTC on 6th October 2026. The first issue was identified proactively by our operations team after monitoring flagged unhealthy call-handling services, before any customer reports were received. The second was reported to our Support team. Service in the Nordics was restored through additional capacity and a software fix on 1st and 2nd October, and the second occurrence was contained with further capacity and a temporary workaround. A permanent fix was then applied across both production environments at 19:00 UTC on 6th October, with all services verified as stable. **Root Cause** A software defect in the way users were allocated across backend servers caused users to be reassigned far more often than intended. Some servers incorrectly reported that they had no remaining capacity, and some users were reassigned again at login despite already having been moved. In the Nordics region, the resulting volume of reassignments placed excessive strain on the supporting database, causing a lock-up. This prevented the call-handling services from completing their routine health checks, so they were taken out of service and users were unable to make or receive calls. The same underlying defect, in which servers incorrectly reported themselves as full, was the cause of the second period of disruption in the EU West region. **Incident Resolution** For the Nordics region, our engineering teams rolled back a recent software release and added further server capacity to spread the load. A software fix was then deployed on 2nd October to resolve the database lock-up, and records that could not be updated during the incident were resynchronised. On 5th October, our development teams identified the cause of the servers incorrectly reporting that they were full. When the same behaviour was reported in the EU West region on 6th October, additional capacity and a temporary workaround were applied to restore service. A permanent fix was built and deployed to both affected production environments at 19:00 UTC on 6th October, and subsequent checks confirmed stable service. **Mitigative Actions** * Refine the user allocation logic to prevent unnecessary reassignment of users. * Strengthen database handling within the call-handling service to prevent lock-ups from affecting service health. * Correct the way backend servers report their available capacity. * Roll out the fixes to all remaining production regions. ### **Timeline** * 01 Oct 2026, 10:28 - Some backend servers reached capacity and began moving users to other servers. The additional activity caused a lock-up in a supporting database, and outgoing calls failed for some of the users who had been moved. * 01 Oct 2026, 11:13 - Our engineering teams convened an incident response and rolled back a recent software release. This reduced the impact but did not fully resolve it. Additional server capacity was also added to spread the load. * 01 Oct 2026, 12:16 - Service stabilised. * 02 Oct 2026, 16:21 - A software fix was deployed to resolve the database lock-up, and records that could not be updated during the incident were resynchronised. * 04 Oct 2026 - The scheduled weekend restart redistributed users more evenly across servers. * 05 Oct 2026 - Our development teams identified why some servers were incorrectly reporting that they were full. * 06 Oct 2026, 08:22 - The same capacity reporting issue was reported in this region. Additional capacity was added and a temporary workaround was applied to restore service. * 06 Oct 2026, 19:00 - A permanent fix was deployed to both the Nordics and EU West production environments, with all services verified as stable.

Started
Oct 02, 2026, 01:08 PM UTC
Resolved
Oct 05, 2026, 04:27 PM UTC
Duration
3d 3h
Detected by Pingoru
Oct 02, 2026, 01:08 PM UTC

Affected components

EU

Update timeline

  1. identified Oct 02, 2026, 01:08 PM UTC

    We are currently investigating an issue affecting ConnectMe in the Nordics region. This is causing intermittent inbound and outbound call failures. Our teams are working to identify the root cause and implement a resolution. A fix is currently being deployed to the affected platform, and the rollout is under close monitoring. This will prevent new occurrences, but some users may still be affected by outdated data. If you experience any issues, logging out and back in again should resolve the problem. In the meantime, we are working to correct the affected user data on our side. Updates will be provided every 60 minutes as we learn more. We apologise for any inconvenience caused and appreciate your patience during this time. Dstny Support

  2. identified Oct 02, 2026, 01:57 PM UTC

    We have identified the root cause of the incident and have prepared an emergency fix. Deployment of the hotfix began from 13:00 UTC and is progressing as planned. We expect the deployment to be completed by 15:00 UTC. Once it has completed, we will let you know so that you can retest straight away. In the meantime, if you experience any issues, logging out and back in again should resolve the problem. We will provide an additional update following the deployment, or sooner if necessary. Thank you for your continued patience and understanding as we work to resolve this matter. Dstny Support

  3. identified Oct 02, 2026, 03:27 PM UTC

    We have identified the root cause of the incident and have prepared an emergency fix. Deployment of the hotfix began from 13:00 UTC and is progressing as planned. The update is still in progress; new ETA expected 16:00 UTC. Once it has completed, we will let you know so that you can retest straight away. In the meantime, if you experience any issues, logging out and back in again should resolve the problem. We will provide an additional update following the deployment, or sooner if necessary. Thank you for your continued patience and understanding as we work to resolve this matter. Dstny Support

  4. monitoring Oct 02, 2026, 05:06 PM UTC

    Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. The hotfix deployment completed at 17:00 UTC. You are welcome to retest now. If you encounter any further problems after the deployment, please raise them with Dstny Support so that we can investigate promptly. Should you still experience issues, logging out and back in again should resolve the problem. We will continue to monitor service availability for the next 24 hours and do not anticipate any further impact at this time. Thank you. Dstny Support

  5. resolved Oct 05, 2026, 04:27 PM UTC

    We are pleased to confirm that this incident has been fully resolved. Over the past 24 hours, we have closely monitored the situation and observed no recurrence or further impact. We have determined the root cause and have implemented measures to prevent future occurrences. To provide transparency and insight into the incident, a detailed post-mortem report will be made available within the next 5 business days. We sincerely apologise for any inconvenience caused and thank you for your patience and understanding throughout this incident. Should you have any further questions or concerns, please feel free to reach out to our support team. Thank you, Dstny Support

  6. postmortem Oct 15, 2026, 09:23 AM UTC

    **Incident Summary** ConnectMe users experienced two separate periods of disruption. In the Nordics region, from 10:28 UTC on 1st October until 16:21 UTC on 2nd October 2026, a subset of users were unable to make or receive calls. A similar issue affected a subset of users in the EU West region from 08:22 UTC until 19:00 UTC on 6th October 2026. The first issue was identified proactively by our operations team after monitoring flagged unhealthy call-handling services, before any customer reports were received. The second was reported to our Support team. Service in the Nordics was restored through additional capacity and a software fix on 1st and 2nd October, and the second occurrence was contained with further capacity and a temporary workaround. A permanent fix was then applied across both production environments at 19:00 UTC on 6th October, with all services verified as stable. **Root Cause** A software defect in the way users were allocated across backend servers caused users to be reassigned far more often than intended. Some servers incorrectly reported that they had no remaining capacity, and some users were reassigned again at login despite already having been moved. In the Nordics region, the resulting volume of reassignments placed excessive strain on the supporting database, causing a lock-up. This prevented the call-handling services from completing their routine health checks, so they were taken out of service and users were unable to make or receive calls. The same underlying defect, in which servers incorrectly reported themselves as full, was the cause of the second period of disruption in the EU West region. **Incident Resolution** For the Nordics region, our engineering teams rolled back a recent software release and added further server capacity to spread the load. A software fix was then deployed on 2nd October to resolve the database lock-up, and records that could not be updated during the incident were resynchronised. On 5th October, our development teams identified the cause of the servers incorrectly reporting that they were full. When the same behaviour was reported in the EU West region on 6th October, additional capacity and a temporary workaround were applied to restore service. A permanent fix was built and deployed to both affected production environments at 19:00 UTC on 6th October, and subsequent checks confirmed stable service. **Mitigative Actions** * Refine the user allocation logic to prevent unnecessary reassignment of users. * Strengthen database handling within the call-handling service to prevent lock-ups from affecting service health. * Correct the way backend servers report their available capacity. * Roll out the fixes to all remaining production regions. ### **Timeline** * 01 Oct 2026, 10:28 - Some backend servers reached capacity and began moving users to other servers. The additional activity caused a lock-up in a supporting database, and outgoing calls failed for some of the users who had been moved. * 01 Oct 2026, 11:13 - Our engineering teams convened an incident response and rolled back a recent software release. This reduced the impact but did not fully resolve it. Additional server capacity was also added to spread the load. * 01 Oct 2026, 12:16 - Service stabilised. * 02 Oct 2026, 16:21 - A software fix was deployed to resolve the database lock-up, and records that could not be updated during the incident were resynchronised. * 04 Oct 2026 - The scheduled weekend restart redistributed users more evenly across servers. * 05 Oct 2026 - Our development teams identified why some servers were incorrectly reporting that they were full. * 06 Oct 2026, 08:22 - The same capacity reporting issue was reported in this region. Additional capacity was added and a temporary workaround was applied to restore service. * 06 Oct 2026, 19:00 - A permanent fix was deployed to both the Nordics and EU West production environments, with all services verified as stable.

Your product runs on more than Dstny

Add the vendors you depend on and get one message when any of them reports trouble. Free for 3 vendors, no card.

Add your stack →