Is Dstny down?

We are investigating a networking issue affecting connectivity to Azure services in the West US region. Impacted customers may experience intermittent connectivity failures, increased latency, or difficulty accessing Azure services. Customers with traffic traversing the West US region may also experience downstream impact.

Microsoft: We identified a recent change that was strongly correlated with the onset of impact. We have completed the rollback of this change and telemetry across services are continuing to show signs of recovery. Customer should be observing recovery at this time. We are closely monitoring service health and downstream recovery and will provide additional updates as we validate restoration This message was last updated at 18:47 UTC on 23 July 2026

On July 23, 2026, a routine device maintenance required isolating specific network paths. Our maintenance process converts these requests into system-readable requests and verifies that at least one of the two redundant paths remains healthy. Before maintenance begins, these requests undergo safety checks to confirm the work will be impact-less. In this case, a bug in the request conversion system incorrectly marked additional devices as a part of the maintenance event and caused a set of IP routes to be removed from more devices than intended. The routes were removed between our datacenter and wide-area network, impacting traffic entering or exiting the region. At 14:44 UTC, customers started experiencing impact and the engineering team was engaged immediately. The issue initially presented as large-scale route churn in our Wide-Area Network (WAN). It was later found that route removal was from a datacenter in the West US region. Once confirmed, engineers began roll back at 17:45 UTC. By 18:26 UTC, the network was restored and healthy, and all impacted services had fully recovered by 19:41 UTC.

**Incident Summary** From 13:49 UTC on 23rd July until 17:37 UTC on 28th July 2026, a subset of users in the US West region experienced intermittent issues registering to Edge SBCs, which impacted the ability to place or receive calls. The issue was proactively detected by our internal monitoring at 14:49 UTC on 23rd July, which identified connectivity failures to specific hosts. Investigation confirmed that the root cause was a regional network outage within the Azure infrastructure. While the primary service impact was mitigated by 18:37 UTC on 23rd July following a vendor-initiated rollback of network changes, the incident remained under observation until final verification was completed on 28th July, with all services verified as stable. **Root Cause** The incident was caused by an external third-party dependency failure. A regional network outage within Microsoft Azure’s US West infrastructure prevented registration traffic from reaching the Edge SBC hosts. This connectivity gap was the result of a network change implemented by the vendor within their environment, which inadvertently disrupted access to multiple hosts in that region. **Incident Resolution** The issue was resolved following a rollback of the problematic network changes by Azure engineering teams. Dstny engineers monitored the restoration of connectivity and confirmed that SSH and registration traffic returned to normal parameters. Throughout the event, the Call2Teams high-availability architecture allowed many customers to transparently fail over to secondary Edge SBCs, significantly limiting the total number of affected users. Final stability checks were performed across the affected region to ensure full service restoration. **Mitigative Actions** Our monitoring and alerting on the SBC platform functioned as intended and enabled the issue affecting our service to be identified and responded to promptly. As part of our continuous improvement activities, we will review opportunities to further enhance visibility of issues affecting external service providers and dependencies, recognising that some vendor-side infrastructure events may not currently be detectable through our existing monitoring capabilities. ### **Timeline** * 23 Jul 2026, 13:49 - Estimated start of service impact. * 23 Jul 2026, 14:49 - Call test alert triggered for US West host; engineering began investigation. * 23 Jul 2026, 15:12 - Affected host taken out of service and restarted to attempt recovery. * 23 Jul 2026, 16:30 - Engineering confirmed multiple hosts in the region were affected by a broader Azure network issue. * 23 Jul 2026, 16:40 - Official vendor notification received regarding US West connectivity issues. * 23 Jul 2026, 17:45 - Vendor initiated a rollback of recent network changes. * 23 Jul 2026, 18:37 - Call test alerts cleared and primary service impact concluded. * 28 Jul 2026, 17:37 - Incident officially closed following extended monitoring and verification.

We are currently investigating an issue affecting SMP in EU-West. This is causing issues for creating and changing users in the affected areas due to no primary number available. Our teams are working to identify the root cause and implement a resolution. Updates will be provided every 60 minutes as we learn more. We apologize for any inconvenience caused and appreciate your patience during this time. Dstny Support

We are currently investigating an issue affecting SMP in all regions excluding US-East, Japan and APAC. This is causing issues when creating or modifying users due to no primary number being available. Our teams are working to identify the root cause and implement a resolution. Updates will be provided every 60 minutes as more information becomes available. We apologise for any inconvenience caused and appreciate your patience while we investigate this issue.

We have identified the root cause of the incident affecting SMP production and staging environments in all regions excluding US-East, Japan and APAC, and have prepared an emergency fix. The hotfix for the production environment is scheduled for deployment at 09:30 UTC (11:30 CEST). Deployment to the staging environment will follow. We will provide a further 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

Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. Service has now been restored, and we do not anticipate any further impact at this time. We will continue to closely monitor service availability over the next 24 hours to ensure stability. Thank you for your patience and understanding throughout this incident. Dstny Support

We are pleased to confirm that this incident affecting SMP production and staging environments in all regions excluding US-East, Japan and APAC has been fully resolved. Over the past 24 hours, we have closely monitored the service and observed no recurrence of the issue or any further impact. The root cause has been identified, and corrective measures have been implemented to restore service and help prevent similar incidents in the future. User creation and modification functionality is now operating as expected across the affected environments. To provide transparency and insight into the incident, a detailed post-mortem report will be made available within the next five 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 contact our Support team. Thank you, Dstny Support

**Incident Summary** From 20:00 UTC on 1st July until 10:40 UTC on 2nd July 2026, a software defect in SMP version 2.4.4 prevented customers from editing primary numbers or creating new users. The issue also affected the assignment of primary numbers to users, ACD groups, Call Distribution Groups \(CDGs\), forwarding numbers and IVRs. Service Provider level functionality was not impacted. The incident affected Production and UAT environments across the Nordics and EU West regions. The issue was identified following reports from partners at 06:54 UTC on 2nd July. Engineering teams developed and deployed a hotfix, with all services verified as stable by 10:40 UTC. **Root Cause** The root cause was a software defect introduced during the release of SMP 2.4.4. A change inadvertently affected application permissions, preventing certain primary number management and user administration actions from being completed. This defect was not identified during testing and validation prior to deployment. **Incident Resolution** Upon declaration of a Major Incident, engineering teams halted further regional rollouts to prevent wider impact. A hotfix was developed and underwent successful testing before being validated in internal and UAT environments. Once the fix was confirmed to restore functionality, it was deployed to all affected production environments. The APAC, US East and Japan regions were not impacted as they remained on version 2.4.3 during the incident. Following successful restoration of the Nordics and EU West regions, the updated SMP 2.4.4 release, including the hotfix, was deployed to these remaining environments. Verification confirmed that user creation and primary number management functionality were fully restored across all regions. **Mitigative Actions** * Expand automated testing to improve defect detection during the release process. * Enhance platform monitoring and tracing to support faster issue detection and diagnosis. ### **Timeline** Incident Summary From 20:00 UTC on 1st July until 10:40 UTC on 2nd July 2026, a software defect in SMP version 2.4.4 prevented customers from editing primary numbers or creating new users. The issue also affected the assignment of primary numbers to users, ACD groups, Call Distribution Groups \(CDGs\), forwarding numbers and IVRs. Service Provider level functionality was not impacted. The incident affected Production and UAT environments across the Nordics and EU West regions. The issue was identified following reports from partners at 06:54 UTC on 2nd July. Engineering teams developed and deployed a hotfix, with all services verified as stable by 10:40 UTC. Root Cause The root cause was a software defect introduced during the release of SMP 2.4.4. A change inadvertently affected application permissions, preventing certain primary number management and user administration actions from being completed. This defect was not identified during testing and validation prior to deployment. Incident Resolution Upon declaration of a Major Incident, engineering teams halted further regional rollouts to prevent wider impact. A hotfix was developed and underwent successful testing before being validated in internal and UAT environments. Once the fix was confirmed to restore functionality, it was deployed to all affected production environments. The APAC, US East and Japan regions were not impacted as they remained on version 2.4.3 during the incident. Following successful restoration of the Nordics and EU West regions, the updated SMP 2.4.4 release, including the hotfix, was deployed to these remaining environments. Verification confirmed that user creation and primary number management functionality were fully restored across all regions. Mitigative Actions * Expand automated testing to improve defect detection during the release process. * Enhance platform monitoring and tracing to support faster issue detection and diagnosis. ### **Timeline** * **1st July, 20:00 UTC:** Deployment of SMP 2.4.4 commences; service impact begins. * **2nd July, 06:54 UTC:** Partners report issues with primary number management and user creation. * **2nd July, 07:35 UTC:** Major Incident declared and technical war room established. * **2nd July, 08:01 UTC:** Global rollouts of SMP 2.4.4 paused to prevent further impact. * **2nd July, 08:47 UTC:** Engineering begins development of a hotfix. * **2nd July, 09:56 UTC:** Hotfix successfully validated in internal environments. * **2nd July, 10:14 UTC:** Hotfix deployed and verified in the UAT environment. * **2nd July, 10:25 UTC:** Deployment of the hotfix to Production environments commences. * **2nd July, 10:40 UTC:** Production restoration confirmed; all services verified as stable.

We are currently investigating an issue affecting the ConnectMe product in the EU West and Nordics regions. This is causing calls to disconnect after 30 minutes for users in the affected areas. Our teams are working to identify the root cause and implement a resolution. 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

We are actively investigating this incident in collaboration with our Platform team and are exploring multiple resolution paths while also working to reproduce the issue. We are implementing measures to reduce user impact wherever possible and will provide a further update within the next 60 minutes. Thank you for your continued patience and understanding during this time. Dstny Support

We are continuing to investigate this incident in collaboration with our Platform team and have identified a potential mitigation, which is currently being tested in a controlled lab environment. Subject to successful validation, we will provide a further update prior to any deployment into the live environment. In parallel, we are continuing to take steps to minimise user impact wherever possible. We will provide the next update within the next 60 minutes. Thank you for your continued patience. Dstny Support

We are continuing to investigate this incident in collaboration with our Platform team and have identified a potential mitigation, which has shown positive results during initial testing. We are now extending testing across all relevant lab environments to ensure the fix is stable and effective. Once validation is complete, we will plan a staged rollout of the fix later this evening. Further updates will be provided as this progresses. In parallel, we continue to take steps to minimise user impact wherever possible. We will provide the next update within the next 60 minutes. Thank you for your continued patience. Dstny Support

We are pleased to confirm that this incident has been fully resolved. Monitoring commenced at 18:45 following the deployment of corrective measures on 12th June and continued over the weekend, during which no recurrence or further impact was observed. We have determined the root cause and 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

**Incident Summary** From 22:00 UTC on the 4th June until 18:00 UTC on the 12th June 2026, a subset of customers using the ConnectMe service in the EU West and Nordics regions experienced unexpected call disconnections after exactly 30 minutes. Following reports of this behaviour, engineering teams identified a software issue and deployed a permanent fix. Service was fully restored at 18:00 UTC on the 12th June, with all services verified as stable. **Root Cause** The issue was caused by a software defect introduced during a recent platform update that affected the handling of call signalling. Specifically, the bug prevented the system from correctly processing "keep-alive" messages and session refresh signals. Because these signals were not being acknowledged, the system incorrectly determined that the call was no longer active once the 30-minute session timer expired, leading to an automatic disconnection. This impact was limited to specific scenarios where session timer configurations differed between the core network and the application. **Incident Resolution** Technical teams identified the specific code error responsible for the signalling failure and developed a permanent software fix. To restore service immediately, engineers adjusted session management settings across the affected call paths to prevent any further premature disconnections. The permanent update was then successfully deployed and validated, ensuring that long-duration calls now remain stable across the network. **Mitigative Actions** * Update system configuration standards to ensure call timers are handled consistently across all service components. * Enhance platform monitoring by adding new metrics to track and alert on session management errors. * Implement new automated production testing specifically focused on validating the stability of long-duration calls. * Review internal deployment procedures to improve the detection of signalling issues during the initial release phase. **Timeline \(UTC\)** * 04 Jun 2026, 22:00 - A scheduled platform update was deployed to the EU West and Nordics regions. * 11 Jun 2026, 08:41 - The first report of 30-minute call disconnections was received by Support. * 12 Jun 2026, 13:07 - A Major Incident was declared following further reports; engineering teams commenced an investigation. * 12 Jun 2026, 15:05 - The root cause was identified, and a software fix was developed and moved into testing. * 12 Jun 2026, 18:00 - The fix was successfully deployed to the production environment, restoring full service stability. * 16 Jun 2026, 11:00 - The fix was deployed to the Staging/UAT environment to ensure all non-production platforms were aligned.

We are currently investigating a potential incident affecting VoiPCube. At this time, the specific regions and the extent of the impact are not yet confirmed. Our teams are actively working to identify the scope of the issue and we will provide updates every 60 minutes as we gather more information. Thank you for your patience as we work to address this matter. Dstny Support

We have identified the root cause of the incident and are currently preparing an emergency fix to address the issue. We will provide an additional update within the next 60 minutes. Thank you for your continued patience and understanding as we work to resolve this matter. Dstny Support

We are writing to inform you that an issue occurred earlier affecting VoIPCube in the EU West and Nordics regions. The incident has been fully resolved, and services have been restored. This may have caused login issues for users attempting to access the platform. We will continue to monitor the situation for the next 24 hours to ensure there is no further impact. Thank you for your understanding, and we appreciate your continued patience. If you have any questions or concerns, please don’t hesitate to contact our support team. Dstny Support

We are pleased to confirm that this incident affecting VoIPCube login in the EU West and Nordics regions has been fully resolved. Over the past 24 hours, we have closely monitored the situation and observed no recurrence or further impact. We have identified the root cause and implemented the necessary fix to restore normal service, along with measures to prevent a similar issue occurring in the future. To provide transparency and further insight, 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

**Incident Summary** From 17:15 UTC on June 10th until 09:20 UTC on June 11th 2026, a subset of users using the VoIPCube client experienced an inability to log in to the service. The issue was triggered by a software release that introduced a change to internal number formatting. Following the identification of the cause, engineering teams deployed a client-side fix and an updated software version to restore login functionality. Service was fully restored by 09:20 UTC on June 11th, with all services verified as stable. **Root Cause** The incident was caused by a change in the logic used to validate user licences during login. When a user did not have a specific short-code alias configured, the system defaulted to using a primary number format containing a "\+" prefix. The VoIPCube client was incompatible with this specific character, leading it to reject the number and prevent user authentication. This incompatibility was not identified prior to the release due to a lack of end-to-end regression testing for users without the optional aliases. **Incident Resolution** To resolve the issue, engineering teams implemented two targeted fixes. For older versions of the client, a server-side adjustment was made to handle the "\+" symbol as a neutral character, bypassing the authentication error. For current versions, an updated client was released that provides native support for the new number format. Following the deployment of these updates and successful partner retesting, normal login functionality was confirmed as restored. **Mitigative Actions** Release Process Alignment: We are further aligning the VoIPCube release programme with our global change standards to ensure enhanced communication and visibility for all service updates. Testing Coverage Expansion: We are broadening our quality assurance framework to include a wider range of configuration scenarios, ensuring even optional user settings are more comprehensively validated before any service changes. **Timeline \(UTC\)** * 10th Jun 2026, 17:15 - Software release deployed; issue triggered. * 11th Jun 2026, 06:36 - First report received and investigation commenced. * 11th Jun 2026, 07:19 - Root cause identified as a number formatting incompatibility. * 11th Jun 2026, 09:20 - Fixes deployed and service functionality confirmed as restored.

We are currently investigating a potential incident affecting Call Recording in the EU West region. Our teams are actively working to determine the scope and impact. Updates will be provided every 60 minutes as further information becomes available. Thank you for your patience while we address this issue. Dstny Support

Impact: Users were unable to log in to the Premium Call Recording portal in the EU West region. Our Platform team has identified the root cause and implemented corrective measures to restore services. We have tested and can confirm that login to the portal is now working as expected. We will continue to monitor service availability over the next 24 hours and do not anticipate any further impact at this time. Thank you for your patience while we addressed this issue. Dstny Support

We are pleased to confirm that this incident has now been fully resolved. Over the past 24 hours, we have closely monitored the service and have seen no recurrence or further impact. The root cause has been identified, and measures have been implemented to prevent a reoccurrence. A detailed post‑incident report will be shared within the next five working days to provide full transparency. We apologise for any inconvenience caused and thank you for your patience during this time. If you have any questions or concerns, please contact our Support team. Kind regards, Dstny Support

**Incident Summary** From 11:33 UTC until 13:30 UTC on 4th June 2026, the Premium Call Recording service for users in the Netherlands and France was unavailable. Impacted users were unable to log into the recording portal or retrieve existing recordings. The issue was identified as a storage platform instability following a network failover. Service was fully restored at 13:30 UTC, with all services verified as stable. **Root Cause** The incident was caused by a hidden software fault within a core router, which was triggered during a routine network configuration update. This fault caused the primary router to fail, forcing traffic to a backup system. Because the backup system had inconsistent configuration settings, the storage platform became unstable and entered a protective "read-only" state. In this state, the system could not process the data required for user logins or recording retrieval. **Incident Resolution** Engineering teams identified the configuration discrepancies on the backup system and used automation tools to redeploy the correct settings. Once the network paths were aligned, the storage platform was successfully restored to full operation. Following the fix, a controlled reboot of the primary router was performed during a later maintenance window to ensure the underlying software fault was cleared. Service was confirmed as stable at 13:30 UTC. **Mitigative Actions** * Perform an emergency software reload on the affected routing hardware to resolve the identified software fault. * Review the Premium Call Recording architecture and storage setup to improve resilience against network failover events. ### **Timeline**