Dstny Outage History

Started Oct 19, 2026, 03:19 PM UTC· resolved Oct 21, 2026, 08:27 AM UTC

1. investigating Oct 19, 2026, 03:19 PM UTC

   Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. 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.

2. monitoring Oct 19, 2026, 03:26 PM UTC

   Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. 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.

3. monitoring Oct 19, 2026, 03:32 PM UTC

   We are writing to inform you that an issue occurred earlier, affecting our Core calling platform, including desktop clients and desk phones, in the Nordics region. The incident has been fully resolved, and services have been restored. This caused inbound calls to fail when answered by an IVR for users in the affected areas. Our Platform team identified the root cause of the issue and implemented corrective measures to restore application services. We will continue to monitor service availability for the next 24 hours to ensure there is no further impact. We do not anticipate any further impact at this time. We apologise for any inconvenience caused, thank you for your understanding, and appreciate your continued patience. If you have any questions or concerns, please do not hesitate to contact our support team. Dstny Support

4. resolved Oct 21, 2026, 08:27 AM 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

5. postmortem Oct 22, 2026, 11:34 AM UTC

   **Incident Summary** Between 14:50 UTC and 15:12 UTC on 19th October 2026, calls to certain numbers in the Nordics region that rely on recorded messages or menus were unable to connect as expected, including automated menus, voicemail and call queues. Multiple partners reported the issue to our Support team. Our engineers quickly located the fault and took corrective action on the affected servers, and normal call handling resumed at 15:12 UTC, with all services verified as stable. **Root Cause** Following planned maintenance on 7th October 2026, new media servers were brought into service. During this work, a process error meant the storage configuration and monitoring safeguards were not applied as intended. As a result, storage capacity on these servers gradually filled over the following days without any alert being raised. By 19th October 2026, capacity was exhausted and the servers could no longer play audio content. **Incident Resolution** Our operations team identified the cause and freed up storage capacity on the affected servers. Service was restored at 15:12 UTC, and normal operation of audio prompts and menus resumed. Monitoring was also introduced at the same time to provide early warning should a similar situation arise. **Mitigative Actions** * Rebuild the affected media servers to a corrected, standardised configuration. * Update installation and setup documentation to reduce the risk of configuration errors. * Enable storage monitoring and alerting across the affected production and test environments. **Timeline** * 07 Oct 2026, 19:00 - Planned maintenance completed and new media servers brought into service. * 19 Oct 2026, 14:50 - Storage capacity was exhausted and affected calls began to fail. * 19 Oct 2026, 14:53 - Our operations team began investigating following partner reports to Support. * 19 Oct 2026, 15:08 - The cause was identified. * 19 Oct 2026, 15:09 - Major incident declared. * 19 Oct 2026, 15:12 - Storage capacity was cleared and normal call handling resumed, with monitoring added to provide early warning of any recurrence.

Read the full incident report →

Started Oct 02, 2026, 01:08 PM UTC· resolved Oct 05, 2026, 04:27 PM UTC

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.

Read the full incident report →

Started Oct 01, 2026, 07:08 AM UTC· resolved Oct 02, 2026, 01:21 PM UTC

1. investigating Oct 01, 2026, 07:08 AM UTC

   We are currently investigating a potential incident affecting SMP. 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

2. monitoring Oct 01, 2026, 08:06 AM UTC

   We are writing to inform you that an issue occurred earlier affecting SMP in the EU West region. The incident has been fully resolved, and services have been restored. This may have caused black screens, performance issues, pages not loading, and slow speeds for users in the affected areas. 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

3. resolved Oct 02, 2026, 01:21 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. In the interest of transparency, 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 do not hesitate to contact our support team. Thank you, Dstny Support

4. postmortem Oct 20, 2026, 04:43 PM UTC

   **Incident Summary** Between 30th September and 1st October 2026, some users and administrators in the EU West region experienced slow performance and intermittent loading problems when using SMP, with the impact building gradually beforehand. The first customer reports were received on 30th September. Service was restored at 08:04 UTC on 1st October once corrective action was taken, with all services verified as stable. **Root Cause** A subset of the servers supporting SMP in EU West ran short of memory, which reduced the capacity available to process customer requests and caused the intermittent slowness. This followed an increase in the temporary data held by the application. Investigations into the origin of this increase are ongoing. **Incident Resolution** Corrective action was taken on the affected servers, which returned the service to normal operation. Service remained stable following the recovery, and the teams continue to review the service to support long-term stability. **Mitigative Actions** * Review how alerts for memory-related issues are allocated and routed, so they reach the correct teams promptly. * Improve logging and monitoring capabilities to speed up the identification and diagnosis of future issues. * Address memory-handling issues within the application that were identified during the investigation. **Timeline** * 29 Sept 2026 - A gradual increase in memory usage was observed on the affected servers, with no customer impact reported. * 30 Sept 2026, 12:30 - Customers first reported slowness and loading problems when using SMP. * 01 Oct 2026, 06:30 - Some users continued to experience intermittent performance issues. * 01 Oct 2026, 06:50 - Further reports were received as additional customers and partners were affected. * 01 Oct 2026, 07:20 - Urgent support cases were raised, prompting a wider review of the service. * 01 Oct 2026 - Investigations linked the issue to memory pressure on a subset of the servers. * 01 Oct 2026, 08:00 - Corrective action was taken on the affected servers. * 01 Oct 2026, 08:04 - Service was restored to normal operation. * 01 Oct 2026, 11:00 - One related report was received after recovery, and reports then tapered off. * 02 Oct 2026, 06:00 - The incident was formally closed, and work continued to establish the origin of the increase in memory usage.

Read the full incident report →

Started Sep 25, 2026, 03:14 PM UTC· resolved Sep 28, 2026, 09:24 AM UTC

1. investigating Sep 25, 2026, 03:14 PM UTC

   We are currently investigating an issue affecting Call2Teams services across the EU and APAC regions. Users in the affected areas may experience issues when making outbound calls. Our teams are actively working to identify the root cause and implement a resolution as quickly as possible. Updates will be provided every 60 minutes as more information becomes available. We apologize for any inconvenience caused and appreciate your patience and understanding during this time. Dstny Support

2. investigating Sep 25, 2026, 04:01 PM UTC

   We have identified the root cause of the incident and have prepared an emergency fix. The hotfix is scheduled for deployment on 25/09/2026 between 8pm and 10pm UTC Time. 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. monitoring Sep 25, 2026, 07:21 PM UTC

   Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. 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.

4. resolved Sep 28, 2026, 09:24 AM UTC

   We are pleased to confirm that this incident has been fully resolved. Following the successful deployment of a hotfix, services have remained stable, and over the past 24 hours we have closely monitored the platform with no recurrence of the issue or further customer impact observed. We have identified the root cause of the incident and implemented corrective measures to prevent a similar occurrence in the future. To provide further 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 do not hesitate to contact our support team. Thank you, Dstny Support

5. postmortem Oct 01, 2026, 02:30 PM UTC

   **Incident Summary** Between 07:00 UTC on 21st September and 21:00 UTC on 25th September 2026, customers using Dstny Call2Teams in all regions experienced intermittent failures when making outbound calls, with some attempts timing out during call set-up. The issue was first reported by a customer at 08:00 UTC on 22nd September and became more frequent once the maintenance rollout completed on 24th September. A corrective change was applied in stages once the cause was identified, and outbound calling was fully restored at 21:00 UTC on 25th September, with all services verified as stable. **Root Cause** A performance-related configuration change, introduced during planned maintenance on 21st September, proved incompatible with how Call2Teams handles outbound calls. An incorrect default setting applied the change more widely than intended, leaving some call-handling components without the security certificates needed to complete call set-up. Calls routed through those components timed out, while others connected normally, which is why the failures were intermittent. The incompatibility was not identified during pre-release testing. **Incident Resolution** Engineering teams disabled the affected performance feature and restarted the relevant services to apply the change. To limit disruption, the fix was deployed outside normal hours, starting with the US, followed by the EU and APAC. Outbound calling was restored at 21:00 UTC on 25th September, and subsequent checks confirmed stable operation across all regions. **Mitigative Actions** * Restore and improve the access needed for configuration synchronisation testing, supporting earlier detection of similar issues. ### **Timeline** * 21 Sept 2026, 07:00 - Planned maintenance rollout begins; intermittent outbound call failures start. * 22 Sept 2026, 08:00 - A customer reports the issue. * 24 Sept 2026, 20:00 - Rollout completes; failures become more frequent. * 25 Sept 2026, 00:00 - Automated monitoring begins alerting on outbound call failures. * 25 Sept 2026, 10:00 - Further alerts received; engineering investigation intensifies. * 25 Sept 2026, 13:00 - Cause identified and a corrective change prepared. * 25 Sept 2026, 14:00 - Corrective change begins rolling out in the US. * 25 Sept 2026, 20:00 - Corrective change begins rolling out in the EU. * 25 Sept 2026, 21:00 - Outbound calling fully restored, with all services verified as stable.

Read the full incident report →

Started Sep 17, 2026, 08:36 PM UTC· resolved Sep 18, 2026, 03:49 PM UTC

1. identified Sep 17, 2026, 08:36 PM UTC

   We are currently investigating reports of intermittent access issues affecting Dstny services in Sweden (SE). This is impacting access to both production and staging environments for some users due to a DNS-related issue affecting dstny.com and dstny.se. The underlying issue has been resolved by our GIS Cloud team. However, due to DNS propagation and caching across internet service providers and local networks, some customers may continue to experience intermittent connectivity or access issues while DNS records are refreshed. Our teams are actively monitoring the situation and will continue to provide updates every 60 minutes or sooner if significant new information becomes available. We apologise for any inconvenience caused and appreciate your patience during this time. Dstny Support

2. identified Sep 17, 2026, 09:08 PM UTC

   The DNS-related issue affecting dstny.com and dstny.se has been resolved by our GIS Cloud team. However, some customers may continue to experience intermittent access issues to Dstny production and staging environments while DNS changes propagate across internet service providers and local networks. If you are still experiencing connectivity issues, we recommend first clearing your local DNS cache. Customers who are familiar with their network settings may also temporarily switch to a public DNS provider such as Cloudflare (1.1.1.1) or Google DNS (8.8.8.8), both of which have been confirmed to have the correct DNS records. We continue to actively monitor the situation and will provide further updates as required. Dstny Support

3. resolved Sep 18, 2026, 03:49 PM UTC

   We are pleased to confirm that the service issues reported under these two related incidents have now been fully resolved. Over the past 24 hours, we have closely monitored the affected services and have observed no further recurrence or impact. Our investigation determined that this incident and the related incident affecting Dstny Zone were both caused by the same underlying issue. Corrective measures have since been implemented to address the root cause and reduce the likelihood of recurrence. To provide transparency and insight into what occurred, a detailed post-mortem report covering the incident, its impact and the actions taken 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 do not hesitate to contact our Support team. Thank you, Dstny Support

4. postmortem Sep 23, 2026, 10:37 AM UTC

   **Incident Summary** From 17:35 UTC on 17th September to 11:00 UTC on 18th September 2026, several Dstny services including Dstny Zone, the Service Management Portal \(SMP\) and voice services such as ConnectMe, Softphone and our Mobile Apps experienced a period of unavailability. We identified the issue at 19:30 UTC on 17th September, following reports of access difficulties. Our engineering teams found that the disruption was caused by a temporary suspension of core domain services, which prevented traffic from reaching the affected platforms. Restoration began immediately. Some services were intermittently restored during the evening as our teams worked through the fix, with full recovery of the majority of services confirmed by 23:14 UTC on 17th September. Final stability checks on the remaining environments were completed the following morning, and the incident was fully resolved by 11:00 UTC on 18th September 2026, with all services confirmed stable. **Root Cause** The incident was caused by an administrative issue relating to our domain registration. A required validation check with our domain registrar was not completed in time, which led to the registrar temporarily suspending the affected domains. This caused a loss of DNS resolution, the system responsible for directing internet traffic to our services, which resulted in unavailability across multiple regions. **Incident Resolution** Our technical teams manually re-established the domain management profiles and restarted the required validation process with the registrar. Once the updated details were confirmed, the suspensions were lifted and traffic resumed normal routing to Dstny services. Following restoration, we migrated all domain contact information to a centralised, monitored management system, so that future registrar notifications are received and acted on promptly. **Mitigative Actions** Improved monitoring: Adding proactive alerting so we're notified directly by our registration provider if a domain is at risk of suspension, rather than relying solely on internal processes. Stronger registrar coordination: Reviewing what happened with our registrar around the time of the incident, and improving communication workflows with external registration partners more broadly. Reduced single points of failure: Assessing whether voice services can use fallback domain names, so they're not dependent on a single domain. Supplier process audit: Conducting a full audit of our registration provider as part of our broader third-party supplier management review. **Timeline** _Prior to 17th Sept_ - An administrative issue with domain contact details was identified following a change in domain management. A request to correct this was submitted but not resolved in time. * 17th Sept 2026, 19:30 - We identified access issues affecting Dstny Zone and began investigating. * 17th Sept 2026, 20:07 - Monitoring confirmed that voice services were also affected. * 17th Sept 2026, 20:20 - Investigation confirmed that a domain suspension was the cause of the outage. Corrected contact details were submitted and services began to recover. * 17th Sept 2026, 21:01 - A further suspension notice was received, showing the issue had not been fully resolved. * 17th Sept 2026, 22:00 - Additional corrective action was taken to finalise the validation process with the registrar. * 17th Sept 2026, 23:14 - All affected domains were confirmed reinstated, restoring the majority of services. * 18th Sept 2026 - Domain contact details were migrated to a centralised, monitored system as a permanent fix. * 18th Sept 2026, 11:00 - Final checks confirmed all environments were stable, and the incident was formally resolved.

5. postmortem Sep 25, 2026, 08:49 AM UTC

   **Incident Summary** From 17:35 UTC on 17th September to 11:00 UTC on 18th September 2026, several Dstny services including Dstny Zone, the Service Management Portal \(SMP\) and voice services such as ConnectMe, Softphone and our Mobile Apps experienced a period of unavailability. We identified the issue at 19:30 UTC on 17th September, following reports of access difficulties. Our engineering teams found that the disruption was caused by a temporary suspension of core domain services, which prevented traffic from reaching the affected platforms. Restoration began immediately. Some services were intermittently restored during the evening as our teams worked through the fix, with full recovery of the majority of services confirmed by 23:14 UTC on 17th September. Final stability checks on the remaining environments were completed the following morning, and the incident was fully resolved by 11:00 UTC on 18th September 2026, with all services confirmed stable. **Root Cause** The incident was caused by an issue on our domain registrar's side. While processing an unrelated administrative change, the registrar set a contact address on our account to one of their own addresses rather than ours. As a result, a subsequent domain verification request did not reach us, and when the verification deadline passed without a response, the registrar suspended the affected domains. This caused a loss of DNS resolution, the system responsible for directing internet traffic to our services, resulting in unavailability across multiple regions. **Incident Resolution** Once the cause was identified, our technical teams worked to have the domains reinstated. An initial attempt to resolve the suspension by moving the domains to an already-verified account did not fully resolve the issue, due to a separate technical fault on the registrar's side. Our teams then established a new domain management profile and completed the full verification process again. Once the registrar confirmed the updated details, the suspensions were lifted and traffic resumed normal routing to Dstny services. Following the incident, we have migrated all domain contact information to a centralised, monitored management system on our side, and worked with our registrar to ensure future verification requests are communicated directly to Dstny rather than through third-party intermediary addresses. **Mitigative Actions** Improved monitoring: Adding proactive alerting so we're notified directly by our registration provider if a domain is at risk of suspension, rather than relying solely on internal processes. Stronger registrar coordination: Reviewing what happened with our registrar around the time of the incident, and improving communication workflows with external registration partners more broadly. Reduced single points of failure: Assessing whether voice services can use fallback domain names, so they're not dependent on a single domain. Supplier process audit: Conducting a full audit of our registration provider as part of our broader third-party supplier management review. **Timeline** Following an unrelated administrative change made by our registrar, a contact address on our domain account was set to a third-party address rather than one belonging to Dstny. As a result, a subsequent routine verification request from the registrar was not received by our team. * 17 Sept 2026, 19:30 - We identified access issues affecting Dstny Zone and began investigating. * 17 Sept 2026, 20:07 - Monitoring confirmed that voice services were also affected. * 17 Sept 2026, 20:20 - Investigation confirmed that a domain suspension was the cause of the outage. Corrected contact details were submitted and services began to recover. * 17 Sept 2026, 21:01 - A further suspension notice was received, showing the issue had not been fully resolved. * 17 Sept 2026, 22:00 - Additional corrective action was taken to finalise the validation process with the registrar. * 17 Sept 2026, 23:14 - All affected domains were confirmed reinstated, restoring the majority of services. * 18 Sept 2026 - Domain contact details were migrated to a centralised, monitored system as a permanent fix. * 18 Sept 2026, 11:00 - Final checks confirmed all environments were stable, and the incident was formally resolved.

Read the full incident report →

Started Sep 17, 2026, 05:59 PM UTC· resolved Sep 18, 2026, 04:03 PM UTC

1. investigating Sep 17, 2026, 05:59 PM UTC

   We are currently investigating a potential incident affecting DstnyZone. 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

2. monitoring Sep 17, 2026, 06:27 PM UTC

   We are writing to inform you that an issue occurred earlier affecting DstnyZone in all regions. The incident has been fully resolved, and services have been restored. This may have caused DstnyZone to be unaccessible for users in the affected areas. 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

3. resolved Sep 18, 2026, 04:03 PM UTC

   Following our investigation, we have confirmed that the service disruption reported under this incident was related to the previously communicated incident, "Ongoing DNS Propagation Causing Intermittent Access to Dstny Services", and both were caused by the same underlying issue. As a result, these incidents have been consolidated and are being managed as a single event. Resolution details, corrective actions and post-mortem information will be communicated under the DNS propagation incident update to avoid duplication and ensure all relevant information is provided in one place. We are pleased to confirm that the issue has been fully resolved, and no further impact has been observed during ongoing monitoring. Thank you for your patience and understanding. Dstny Support

4. postmortem Sep 24, 2026, 08:21 AM UTC

   **Incident Summary** From 17:35 UTC on 17th September to 11:00 UTC on 18th September 2026, several Dstny services including Dstny Zone, the Service Management Portal \(SMP\) and voice services such as ConnectMe, Softphone and our Mobile Apps experienced a period of unavailability. We identified the issue at 19:30 UTC on 17th September, following reports of access difficulties. Our engineering teams found that the disruption was caused by a temporary suspension of core domain services, which prevented traffic from reaching the affected platforms. Restoration began immediately. Some services were intermittently restored during the evening as our teams worked through the fix, with full recovery of the majority of services confirmed by 23:14 UTC on 17th September. Final stability checks on the remaining environments were completed the following morning, and the incident was fully resolved by 11:00 UTC on 18th September 2026, with all services confirmed stable. **Root Cause** The incident was caused by an administrative issue relating to our domain registration. A required validation check with our domain registrar was not completed in time, which led to the registrar temporarily suspending the affected domains. This caused a loss of DNS resolution, the system responsible for directing internet traffic to our services, which resulted in unavailability across multiple regions. **Incident Resolution** Our technical teams manually re-established the domain management profiles and restarted the required validation process with the registrar. Once the updated details were confirmed, the suspensions were lifted and traffic resumed normal routing to Dstny services. Following restoration, we migrated all domain contact information to a centralised, monitored management system, so that future registrar notifications are received and acted on promptly. **Mitigative Actions** Improved monitoring: Adding proactive alerting so we're notified directly by our registration provider if a domain is at risk of suspension, rather than relying solely on internal processes. Stronger registrar coordination: Reviewing what happened with our registrar around the time of the incident, and improving communication workflows with external registration partners more broadly. Reduced single points of failure: Assessing whether voice services can use fallback domain names, so they're not dependent on a single domain. Supplier process audit: Conducting a full audit of our registration provider as part of our broader third-party supplier management review. **Timeline** * Prior to 17th Sept - An administrative issue with domain contact details was identified following a change in domain management. A request to correct this was submitted but not resolved in time. * 17th Sept 2026, 19:30 - We identified access issues affecting Dstny Zone and began investigating. * 17th Sept 2026, 20:07 - Monitoring confirmed that voice services were also affected. * 17th Sept 2026, 20:20 - Investigation confirmed that a domain suspension was the cause of the outage. Corrected contact details were submitted and services began to recover. * 17th Sept 2026, 21:01 - A further suspension notice was received, showing the issue had not been fully resolved. * 17th Sept 2026, 22:00 - Additional corrective action was taken to finalise the validation process with the registrar. * 17th Sept 2026, 23:14 - All affected domains were confirmed reinstated, restoring the majority of services. * 18th Sept 2026 - Domain contact details were migrated to a centralised, monitored system as a permanent fix. * 18th Sept 2026, 11:00 - Final checks confirmed all environments were stable, and the incident was formally resolved.

5. postmortem Sep 25, 2026, 08:57 AM UTC

   **Incident Summary** From 17:35 UTC on 17th September to 11:00 UTC on 18th September 2026, several Dstny services including Dstny Zone, the Service Management Portal \(SMP\) and voice services such as ConnectMe, Softphone and our Mobile Apps experienced a period of unavailability. We identified the issue at 19:30 UTC on 17th September, following reports of access difficulties. Our engineering teams found that the disruption was caused by a temporary suspension of core domain services, which prevented traffic from reaching the affected platforms. Restoration began immediately. Some services were intermittently restored during the evening as our teams worked through the fix, with full recovery of the majority of services confirmed by 23:14 UTC on 17th September. Final stability checks on the remaining environments were completed the following morning, and the incident was fully resolved by 11:00 UTC on 18th September 2026, with all services confirmed stable. **Root Cause** The incident was caused by an issue on our domain registrar's side. While processing an unrelated administrative change, the registrar set a contact address on our account to one of their own addresses rather than ours. As a result, a subsequent domain verification request did not reach us, and when the verification deadline passed without a response, the registrar suspended the affected domains. This caused a loss of DNS resolution, the system responsible for directing internet traffic to our services, resulting in unavailability across multiple regions. **Incident Resolution** Once the cause was identified, our technical teams worked to have the domains reinstated. An initial attempt to resolve the suspension by moving the domains to an already-verified account did not fully resolve the issue, due to a separate technical fault on the registrar's side. Our teams then established a new domain management profile and completed the full verification process again. Once the registrar confirmed the updated details, the suspensions were lifted and traffic resumed normal routing to Dstny services. Following the incident, we have migrated all domain contact information to a centralised, monitored management system on our side, and worked with our registrar to ensure future verification requests are communicated directly to Dstny rather than through third-party intermediary addresses. **Mitigative Actions** Improved monitoring: Adding proactive alerting so we're notified directly by our registration provider if a domain is at risk of suspension, rather than relying solely on internal processes. Stronger registrar coordination: Reviewing what happened with our registrar around the time of the incident, and improving communication workflows with external registration partners more broadly. Reduced single points of failure: Assessing whether voice services can use fallback domain names, so they're not dependent on a single domain. Supplier process audit: Conducting a full audit of our registration provider as part of our broader third-party supplier management review. **Timeline** Following an unrelated administrative change made by our registrar, a contact address on our domain account was set to a third-party address rather than one belonging to Dstny. As a result, a subsequent routine verification request from the registrar was not received by our team. * 17 Sept 2026, 19:30 - We identified access issues affecting Dstny Zone and began investigating. * 17 Sept 2026, 20:07 - Monitoring confirmed that voice services were also affected. * 17 Sept 2026, 20:20 - Investigation confirmed that a domain suspension was the cause of the outage. Corrected contact details were submitted and services began to recover. * 17 Sept 2026, 21:01 - A further suspension notice was received, showing the issue had not been fully resolved. * 17 Sept 2026, 22:00 - Additional corrective action was taken to finalise the validation process with the registrar. * 17 Sept 2026, 23:14 - All affected domains were confirmed reinstated, restoring the majority of services. * 18 Sept 2026 - Domain contact details were migrated to a centralised, monitored system as a permanent fix. * 18 Sept 2026, 11:00 - Final checks confirmed all environments were stable, and the incident was formally resolved.

Read the full incident report →

Started Sep 17, 2026, 09:20 AM UTC· resolved Sep 21, 2026, 08:50 AM UTC

1. investigating Sep 17, 2026, 09:20 AM UTC

   We are investigating an issue affecting the Android & iOS mobile app following the release of version 7.0.1. Some users may experience the app crashing or calls disconnecting when placing a call on hold, transferring a call or attempting to add a second call. Our teams are actively investigating the issue. We will provide further updates as more information becomes available.

2. resolved Sep 21, 2026, 08:50 AM UTC

   We are pleased to confirm that this issue has now been fully resolved. A fix has been implemented to address the behaviour introduced in mobile app version 7.0.1 that could, in certain scenarios, cause the application to crash or calls to disconnect when placing a call on hold, transferring a call, or adding a second call. Following deployment of the fix, we have closely monitored the service and have observed no further recurrence of the issue. Measures have also been put in place to help prevent similar issues occurring in future releases. We sincerely apologise for any inconvenience caused and thank you for your patience and understanding while we investigated and resolved this matter. Should you have any questions or continue to experience any issues, please contact our Support Team. Thank you, Dstny Support

Read the full incident report →

Started Aug 31, 2026, 08:19 AM UTC· resolved Aug 31, 2026, 09:46 AM UTC

1. investigating Aug 31, 2026, 08:19 AM UTC

   We are currently investigating an issue affecting Call2Teams certificate provisioning, which may impact calling functionality for some customers. We will provide a further update once we have confirmed progress or additional information.

Read the full incident report →

Started Aug 25, 2026, 10:25 AM UTC· resolved Sep 01, 2026, 02:06 PM UTC

1. investigating Aug 25, 2026, 10:25 AM UTC

   As a precautionary security measure, the Forgot Password functionality has been temporarily disabled while we implement and test a security update. This does not affect normal access for users who already know their credentials. However, password resets will be unavailable until the update has been completed and validated. We are actively working to restore this functionality as quickly as possible. We apologise for any inconvenience and will provide further updates as they become available.

2. investigating Aug 25, 2026, 11:23 AM UTC

   As a precautionary security measure, the Forgot Password functionality has been temporarily disabled across affected Dstny applications in all regions, including ConnectMe, SMP, CRM Connect, Teams Connect and Dstny Zone. This only affects users who need to reset their password. Users who already know their password can continue to log in and use services as normal. We are actively working to restore this functionality and will provide further updates as they become available.

3. investigating Aug 26, 2026, 12:52 PM UTC

   Our engineering teams are continuing work to restore the Forgot Password functionality across the remaining affected Dstny services. Forgot Password has now been restored for Dstny Zone. Work is ongoing for the remaining applications, and we will provide a further update once there is confirmed progress.

4. investigating Aug 27, 2026, 03:24 PM UTC

   Progress has been made towards restoring the Forgot Password functionality across the remaining affected Dstny services. The updated solution has successfully completed initial testing, with no issues identified. Deployment to our staging environments is now progressing so that we can complete further validation and performance testing before proceeding with the production rollout. We will provide a further update as the rollout progresses.

5. monitoring Aug 31, 2026, 04:52 PM UTC

   The Forgot Password functionality has now been fully restored across all affected Dstny applications, including ConnectMe, SMP, CRM Connect, Teams Connect and Dstny Zone. Users can now reset their passwords as usual. No further action is required. Our teams will continue to monitor the service closely to confirm stability. We apologise for the inconvenience caused while the security update was implemented and validated, and thank you for your patience throughout.

6. resolved Sep 01, 2026, 02:06 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Aug 10, 2026, 11:15 AM UTC· resolved Aug 13, 2026, 02:19 PM UTC

1. investigating Aug 10, 2026, 11:15 AM UTC

   We are currently investigating a potential incident affecting the Call2Teams platform. At this time, multiple customers are experiencing registration failures, however the specific affected Edge SBCs and regions have not yet been confirmed. Our engineering teams are actively investigating the issue to determine the scope and impact, and we will provide updates every 60 minutes as more information becomes available. Thank you for your patience as we work to address this matter. Dstny Support

2. investigating Aug 10, 2026, 12:28 PM UTC

   We continue to investigate the issue affecting the Call2Teams platform, where multiple customers are experiencing registration failures. The affected Edge SBCs and regions are still being assessed. Engineering teams remain actively engaged and are working on mitigation measures to restore service as quickly as possible. We will continue to provide updates every 60 minutes or sooner if significant new information becomes available. Thank you for your patience. Dstny Support

3. investigating Aug 10, 2026, 01:34 PM UTC

   We have identified that the EU region is affected by the ongoing Call2Teams incident, with customers experiencing registration failures. Our Engineering teams remain actively engaged and are continuing to investigate the underlying cause, overall scope, and any additional affected regions or Edge SBCs. Work is ongoing to determine the appropriate mitigation and restore service as quickly as possible.

4. monitoring Aug 10, 2026, 03:39 PM UTC

   Service has now been restored in the affected EU region, and Call2Teams registrations have returned to normal. Our Engineering teams have taken mitigation actions and are continuing to monitor the platform to ensure service remains stable.

5. monitoring Aug 11, 2026, 03:56 PM UTC

   Service remains stable following the restoration activities, and no further customer impact has been observed at this time. Our Engineering teams are continuing to investigate the underlying root cause of the incident and are maintaining enhanced monitoring while this work is completed. Although we do not currently anticipate any further impact, the incident will remain under review until the root cause has been fully understood and any additional preventative actions have been identified. Thank you for your patience. Dstny Support.

6. monitoring Aug 12, 2026, 02:47 PM UTC

   Service remains stable following the restoration activities, and no further customer impact has been observed in the affected EU and US regions. Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. Monitoring has been enhanced and additional operational safeguards have been introduced to improve visibility and support rapid response should similar conditions occur in future. Although reports from the US region were only identified later in the investigation, services have since been restored and both affected regions are now considered resolved and operating normally. We will continue to closely monitor service availability for the next 24 hours and do not anticipate any further impact at this time. Thank you for your patience. Dstny Support.

7. resolved Aug 13, 2026, 02:19 PM UTC

   We are pleased to confirm that this incident has been fully resolved. Following the restoration activities and an extended period of enhanced monitoring, no further customer impact or recurrence has been observed across the affected EU and US regions. Our Platform and Engineering teams have completed their investigation, identified the root cause, and implemented corrective and preventative measures to reduce the likelihood of similar incidents occurring in future. Additional monitoring and operational safeguards have also been introduced to improve visibility and support rapid response should similar conditions arise. A detailed post-mortem report will be published within the next 5 business days to provide further transparency into the incident, its cause, and the actions taken. We sincerely apologise for any inconvenience caused and thank you for your patience and understanding throughout this incident. Should you have any questions or concerns, please contact our Support team. Thank you, Dstny Support

8. postmortem Aug 26, 2026, 11:35 AM UTC

   **Incident Summary** From 20:05 UTC on 9th August until 20:50 UTC on 15th August 2026, a subset of customers in Europe and the US were unable to receive inbound calls via Microsoft Teams due to a failure in the Call2Teams platform’s ability to manage customer connections. The issue was reactively identified following customer reports on 10th August, with initial recovery for European services achieved by 15:00 UTC that day. However, intermittent connectivity issues persisted for US-based users until a final service restart and the implementation of enhanced monitoring on 15th August, with all services verified as stable. **Root Cause** The investigation identified a software defect within the service responsible for managing user connections. This defect prevented the system from correctly releasing resources when processing certain errors. Over time, these unreleased resources accumulated in the platform's in-memory database until it reached its maximum capacity. Once this limit was hit, the system could no longer process new connection requests, leading to a loss of connectivity for multiple users during the incident. **Incident Resolution** Technical teams restored service by manually reassigning affected customers to alternative connection points and performing targeted restarts of the impacted software components and in-memory databases. To ensure long-term stability, engineering teams implemented new alerting and monitoring dashboards to provide better visibility into resource consumption. The incident was considered fully resolved once these proactive monitoring tools were in place and service stability was confirmed across all regions. **Mitigative Actions** * Implement software updates to improve resource management and error handling within the connection service. * Enhance platform monitoring and alerting to provide earlier visibility into system resource utilisation. * Optimise system logging configurations to improve diagnostic capabilities and data management. * Conduct a comprehensive review of platform alerting logic to ensure more proactive detection of service degradations. **Timeline** * 09 Aug 2026, 20:05 - Initial service disruption begins for a subset of users in the European region. * 10 Aug 2026, 08:00 - Service disruption begins for a subset of users in the US region. * 10 Aug 2026, 11:06 - A Major Incident is formalised following reports of connectivity issues. * 10 Aug 2026, 11:40 - Technical teams begin migrating affected users to alternative connection points. * 10 Aug 2026, 13:45 - Restoration activities commence for impacted European services. * 10 Aug 2026, 15:00 - European services are restored and enter a period of monitoring. * 12 Aug 2026, 07:00 - Further connectivity issues are identified affecting users in the US region. * 12 Aug 2026, 15:19 - Enhanced monitoring and dashboards are deployed to improve visibility. * 15 Aug 2026, 20:50 - Final service restarts are completed in the US, resolving all remaining impact. * 15 Aug 2026, 21:30 - All services are verified as stable across all regions.

Read the full incident report →

Started Aug 03, 2026, 10:11 AM UTC· resolved Aug 03, 2026, 11:05 AM UTC

1. resolved Aug 03, 2026, 10:11 AM UTC

   We are writing to inform you that an issue occurred earlier affecting the ConnectMe service within the Eu-West-Bru Production region. Both UAT and Production environments were affected. The incident has now been fully resolved, and services have been restored. During the incident, Easybell, and ODOS BE and Flexfone DK customers may have experienced an inability to access or use the ConnectMe service. We will continue to monitor the platform for the next 24 hours to ensure service stability and confirm there is no further impact. Thank you for your understanding and patience. If you have any questions or concerns, please do not hesitate to contact our Support team. Kind regards, Dstny Support

2. postmortem Aug 11, 2026, 03:24 PM UTC

   **Incident Summary** On 3rd August 2026, between 08:55 UTC and 10:11 UTC, the ConnectMe application became unavailable for customers in Germany, Belgium and Denmark. Both the production and staging environments were affected. Users were unable to log in to the application, while those already logged in were disconnected when refreshing their session. The incident was identified through a combination of automated alerting and customer reports, and engineering teams were engaged promptly to investigate and restore service. Full service was confirmed as restored at 10:11 UTC, with both production and staging services verified as stable. **Root Cause** The incident was caused by a historical configuration issue within the underlying storage infrastructure. During previous infrastructure changes, a critical platform setting was not identified for review, leaving the environment unable to accommodate certain internal workload changes. When one of these changes occurred, the storage service became unavailable, which caused the content delivery service relied upon by ConnectMe to fail. As a result, ConnectMe was unavailable for the duration of the incident. **Incident Resolution** Once the root cause was identified as a storage infrastructure issue, the relevant infrastructure team was engaged to restore the affected storage platform. Following recovery of the storage service, the dependent services recovered automatically, and ConnectMe returned to normal operation. Full service was confirmed as restored at 10:11 UTC on 3rd August 2026. **Mitigative Actions** * **Review and update storage platform configuration** to reduce the risk of similar service disruptions occurring in future. * **Assess monitoring and alerting capabilities** to improve the early detection of infrastructure issues. * **Conduct a broader review of storage platform dependencies** to identify and address any related configuration risks. **Timeline** * 03 Aug 2026, 08:55 - Automated monitoring detected a potential service issue and alerted the support team. * 03 Aug 2026, 09:00 - Initial investigation began to determine the scope and cause of the disruption. * 03 Aug 2026, 09:08 - Early recovery actions were carried out while the investigation continued. * 03 Aug 2026, 09:20 - Customer impact was confirmed and the Major Incident process was initiated. * 03 Aug 2026, 09:27 - Relevant engineering teams were engaged and a coordinated incident response was established. * 03 Aug 2026, 09:35 - Further remediation activities were undertaken based on investigation findings. * 03 Aug 2026, 09:45 - Infrastructure specialists joined the investigation after the issue was traced to the underlying storage platform. * 03 Aug 2026, 10:04 - The affected storage services were restored.The affected storage services were restored. * 03 Aug 2026, 10:10 - ConnectMe services were confirmed as operational following recovery of the underlying infrastructure. * 03 Aug 2026, 10:11 - Service restoration was fully verified and the incident was declared resolved.

Read the full incident report →

Started Jul 23, 2026, 05:09 PM UTC· resolved Jul 23, 2026, 08:00 PM UTC

1. investigating Jul 23, 2026, 05:09 PM UTC

   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.

2. identified Jul 23, 2026, 07:19 PM UTC

   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

3. resolved Jul 24, 2026, 08:05 AM UTC

   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.

4. postmortem Jul 30, 2026, 03:41 PM 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.

Read the full incident report →

Started Jul 02, 2026, 08:11 AM UTC· resolved Jul 03, 2026, 10:00 AM UTC

1. investigating Jul 02, 2026, 08:11 AM UTC

   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

2. investigating Jul 02, 2026, 08:11 AM UTC

   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.

3. identified Jul 02, 2026, 09:21 AM UTC

   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

4. monitoring Jul 02, 2026, 10:55 AM UTC

   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

5. resolved Jul 03, 2026, 10:00 AM UTC

   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

6. postmortem Jul 08, 2026, 09:05 AM UTC

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

Read the full incident report →

Started Jun 12, 2026, 01:23 PM UTC· resolved Jun 15, 2026, 11:57 AM UTC

1. investigating Jun 12, 2026, 01:23 PM UTC

   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

2. investigating Jun 12, 2026, 02:46 PM UTC

   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

3. investigating Jun 12, 2026, 03:47 PM UTC

   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

4. identified Jun 12, 2026, 04:55 PM UTC

   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

5. resolved Jun 15, 2026, 11:57 AM UTC

   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

6. postmortem Jun 18, 2026, 02:20 PM UTC

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

Read the full incident report →

Started Jun 11, 2026, 08:14 AM UTC· resolved Jun 12, 2026, 10:45 AM UTC

1. investigating Jun 11, 2026, 08:14 AM UTC

   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

2. identified Jun 11, 2026, 08:14 AM UTC

   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

3. monitoring Jun 11, 2026, 09:26 AM UTC

   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

4. resolved Jun 12, 2026, 10:45 AM UTC

   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

5. postmortem Jun 16, 2026, 02:46 PM UTC

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

Read the full incident report →

Started Jun 04, 2026, 11:06 AM UTC· resolved Jun 05, 2026, 12:17 PM UTC

1. investigating Jun 04, 2026, 11:06 AM UTC

   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

2. monitoring Jun 04, 2026, 11:39 AM UTC

   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

3. resolved Jun 05, 2026, 12:17 PM UTC

   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

4. postmortem Jun 12, 2026, 03:56 PM UTC

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

Read the full incident report →

Started May 18, 2026, 10:38 AM UTC· resolved May 19, 2026, 01:40 PM UTC

1. investigating May 18, 2026, 10:38 AM UTC

   We are currently investigating a potential incident affecting Dynamic Emergency Trunk (DET) services for Call2Teams across all regions. Our teams are working to determine the scope and impact, and we will provide further updates every 60 minutes as more information becomes available. Thank you for your patience while we investigate. Dstny Support

2. investigating May 18, 2026, 11:48 AM UTC

   Engineering are continuing to investigate to determine the full impact, root cause, and an appropriate resolution. We will provide a further update in 60 minutes. Thank you for your patience. Dstny Support

3. investigating May 18, 2026, 12:36 PM UTC

   Service stability has improved following initial recovery actions, and we are now focusing on identifying and addressing the primary underlying cause. Engineering continue to work to determine the full impact and implement a resolution. We will provide a further update in 60 minutes. Dstny Support

4. monitoring May 18, 2026, 12:51 PM UTC

   Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. 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 May 19, 2026, 01:40 PM UTC

   We are pleased to confirm that this incident has now been fully resolved. Over the past 24 hours, monitoring has shown no recurrence or further impact. The root cause has been identified, and measures have been implemented to prevent recurrence. A detailed post-mortem report will be shared within the next five business days. We apologise for any inconvenience caused and thank you for your patience and understanding. If you have any further questions, please contact our Support team. Thank you, Dstny Support

6. postmortem May 22, 2026, 02:26 PM UTC

   **Incident Summary** From 00:37 UTC on 17th May to 12:45 UTC on 18th May 2026, DET emergency trunk calling for Call2Teams was unavailable across all regions. The issue occurred following a host restart, which prevented network traffic from reaching the emergency trunks. While the service was impacted throughout this period, investigations confirmed that no customer emergency calls were attempted while the trunks were offline. Service was fully restored at 12:45 UTC on 18th May, with stability verified. **Root Cause** During an infrastructure restart, an automated system security service unintentionally activated and blocked essential network ports. This occurred due to a configuration oversight within the automation scripts and manual setup, which failed to ensure the service remained disabled upon reboot. This resulted in the emergency trunks being unable to establish the required network connections for call processing. **Incident Resolution** Engineering teams identified that the security service was active on the affected hosts and manually stopped the process. This immediately restored network connectivity, and all emergency trunks returned to a stable state. Final verification testing was completed at 12:45 UTC on 18th May, confirming that all regions were once again able to process emergency traffic correctly. **Mitigative Actions** * Permanently remove the conflicting security software from all relevant virtual machines to ensure they are reboot-safe. * Adjust call tester alerts and notification workflows to ensure faster escalation and investigation of availability warnings. * Improve internal logging and reporting for emergency trunk traffic to allow for more rapid impact assessment.

Read the full incident report →

Started Apr 14, 2026, 11:01 AM UTC· resolved Apr 16, 2026, 02:15 PM UTC

1. investigating Apr 14, 2026, 11:01 AM UTC

   We are currently investigating an issue affecting Call2Teams across multiple regions. At this time, the specific regions and the full extent of the impact are not yet confirmed. This issue may cause intermittent loss of audio at the start of calls or during internal call transfers, impacting both inbound and outbound calls. Our teams are actively 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

2. identified Apr 14, 2026, 11:47 AM UTC

   We are currently investigating an issue affecting Call2Teams in the EU West region. This issue is causing one‑way or no audio at the start of calls and during internal call transfers, impacting users in the affected area. Our teams are working to identify the root cause and implement a resolution. In parallel, our Platform Engineering team is actively working on implementing an urgent fix, with further updates to follow. 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

3. monitoring Apr 14, 2026, 12:55 PM UTC

   We are writing to inform you that an issue occurred earlier affecting Call2Teams in the EU region. A mitigation has now been successfully implemented, and services have been restored. This issue may have caused one‑way or no audio at the start of calls or during internal call transfers for users in the affected area. We will continue to monitor the situation closely over 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

4. identified Apr 15, 2026, 09:37 AM UTC

   We are currently investigating an issue caused by a bug within our application code. Recent changes introduced by Microsoft appear to have exacerbated the behaviour, which brought the issue to our attention. Our engineering teams are actively working to identify the root cause and implement a fix, with the aim of addressing this today where feasible. As a temporary workaround, limiting usage to a single codec should help minimise impact in the interim. We will provide further updates as more information becomes available. We apologise for any inconvenience caused and appreciate your patience. Dstny Support

5. identified Apr 15, 2026, 10:44 AM UTC

   Following our previous update, we have now tested a new solution that addresses the identified issue and early results are positive. The fix is currently being validated with a small number of targeted customer accounts. Subject to the outcome of this testing, we expect to provide a further update regarding a wider rollout. In the meantime, the previously shared workaround remains applicable to minimise impact. We will continue to keep you informed as we progress. Thank you for your continued patience. Dstny Support

6. identified Apr 15, 2026, 12:15 PM UTC

   Due to our deployment pipeline setup, the rollout is expected to take up to one hour from this point, rather than the 30 minutes previously advised. We will provide a further update once the rollout has completed. Thank you for your continued patience and understanding. Dstny Support

7. monitoring Apr 15, 2026, 01:25 PM UTC

   Our Platform team has identified the root cause and implemented corrective measures to restore normal service. Customers are not expected to have experienced any impact. A small number may have seen a brief call setup failure during deployment, which would have cleared on redial, or short‑lived re‑registrations as part of normal update behaviour. Service is now stable, and we are moving into a monitoring phase. We will continue to closely monitor availability over the next 24 hours and do not anticipate any further impact at this time. Customers may also revert to their previous codec settings if required. Thank you for your patience and understanding. Dstny Support

8. resolved Apr 16, 2026, 02:15 PM UTC

   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 observed no recurrence or further impact. The root cause has been identified, and preventative measures have been implemented to reduce the risk of a similar issue occurring in future. To provide transparency, a detailed post‑mortem report will be shared 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 do not hesitate to contact our Support team. Kind regards, Dstny Support

9. postmortem Apr 21, 2026, 02:54 PM UTC

   **Incident Summary** From 13:45 UTC on 13th April 2026 until 11:29 UTC on 15th April 2026, a subset of Call2Teams customers experienced intermittent call quality issues. Reported symptoms included one‑way audio, silence at the start of calls or during internal transfers, intermittent static, and in some cases early call termination shortly after connection. While initial reports suggested a possible regional limitation, investigation confirmed that affected scenarios could occur across all regions. Following a series of targeted fixes and monitoring, full service was restored and confirmed stable by 11:29 UTC on 15th April 2026. **Root Cause** The incident was caused by an interaction between a change in Microsoft’s call setup behaviour and a previously latent issue in the Call2Teams call setup logic. Microsoft’s updated codec selection exposed a defect in how our platform handled codec ordering in certain responses, which could create mismatches between the codec signalled to customer phone systems and the codec used towards Microsoft. In parallel, G.722 was being advertised to Microsoft in line with SBC vendor guidance and earlier interoperability assumptions, leading Microsoft to select G.722 in cases where some customer PBXs did not support it. Together, these factors increased real‑time transcoding and contributed to the intermittent audio problems observed. **Incident Resolution** Engineers first reduced unnecessary transcoding by adjusting configuration so that G.722 is only offered to Microsoft when it is explicitly supported by the customer’s phone system. Outside of the standard default codecs \(PCMA and PCMU\), advertised codecs were aligned with each customer’s PBX capabilities, which immediately improved platform stability. A software update was then deployed to correct call setup handling so that codec selections negotiated with Microsoft are maintained consistently when signalled back to customer systems. Following rollout, targeted testing, and monitoring, call quality was confirmed to be stable across all affected scenarios. **Mitigative Actions** We have corrected the call setup logic to prevent incorrect codec re‑ordering from being signalled to customer systems, ensuring that codec selections negotiated with Microsoft are preserved end‑to‑end. We have also reduced unnecessary transcoding by limiting advertised codecs to standard defaults \(PCMA and PCMU\), while conditionally including other codecs, such as G.722, only where they are explicitly supported by the customer’s phone system. In addition, we are reviewing our SBC configuration and internal processes to improve early detection of, and response to, third‑party behavioural changes, strengthening overall service resilience and reducing the likelihood of similar incidents recurring. ### **Timeline**

Read the full incident report →

Started Apr 02, 2026, 04:05 AM UTC· resolved Apr 02, 2026, 07:37 AM UTC

1. resolved Apr 02, 2026, 08:23 AM UTC

   We are writing to inform you that an issue occurred earlier affecting ConnectMe in EU-West. The incident has been fully resolved, and services have been restored. This may have caused failing outbound calls for users in the affected areas. 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.

2. postmortem Apr 09, 2026, 11:03 AM UTC

   **Incident Summary** On 2nd April 2026, between 04:05 UTC and 07:37 UTC, a routine software update in the EU West region led to intermittent call failures for a subset of ConnectMe users. The issue was proactively detected, and service was fully restored after the update was rolled back at 07:37 UTC. All systems were subsequently verified as stable. **Root Cause** The incident was triggered by a routine software update aimed at enhancing service recovery within the ConnectMe platform. During deployment, the update caused an unexpected interaction within the system, leading to a key component becoming unresponsive and resulting in intermittent outbound call failures for some users. **Incident Resolution** The issue was resolved by rolling back the software update to the previous stable version at 07:37 UTC. This action restored normal service for all users. The rollback was performed promptly after the root cause was identified, and service stability was closely monitored to confirm full recovery. **Mitigative Actions** We are refining monitoring to better detect outbound call failures and reviewing the upgrade process to address identified gaps. Backend adjustments will also be made to improve stability in future deployments.

Read the full incident report →

Started Mar 03, 2026, 04:40 PM UTC· resolved Mar 04, 2026, 05:33 PM UTC

1. investigating Mar 03, 2026, 04:40 PM UTC

   We are currently investigating an issue affecting Call2Teams in the US West region. This is resulting in registration loss and failed inbound and outbound calls for users in the affected areas. Our teams are working to identify the root cause and implement a resolution. We have received reports that some users are already regaining service while engineering teams continue to apply mitigating actions. We will provide updates every 60 minutes as more information becomes available. We apologise for any inconvenience caused and appreciate your patience while we work to restore full service.

2. monitoring Mar 03, 2026, 05:29 PM UTC

   Our Platform Team has identified the root cause of the issue and implemented corrective actions to fully restore application services. We will continue to closely monitor service availability over the next 24 hours, and no further impact is expected at this time. Thank you, Dstny Support

3. resolved Mar 04, 2026, 05:33 PM UTC

   We are pleased to confirm that this incident has now been fully resolved. Over the past 24 hours, we have monitored the service closely and have seen no recurrence or further impact. We have identified the root cause and implemented measures to prevent similar incidents in the future. For full transparency, a detailed post‑incident report will be made available within the next five business days. We sincerely apologise for any inconvenience caused and appreciate your patience and understanding throughout this incident. If you have any further questions or concerns, please contact our support team. Thank you, Dstny Support

4. postmortem Mar 09, 2026, 04:27 PM UTC

   **Incident Summary** On 3rd March 2026, a subset of Call2Teams users in the US region experienced disruption to their calling services. Between 12:55 UTC and 16:50 UTC, users served by one of our Edge signalling SBCs were unable to register successfully, which prevented them from making or receiving calls during this period. Full service was restored for all affected users by 16:50 UTC. **Root Cause** The root cause was introduced during routine maintenance on one of our Edge signalling SBCs. Following a software upgrade, essential services were not restarted as required, leaving the SBC unable to process user registrations. This resulted in affected users being unable to establish calls during the disruption window. **Incident Resolution** Initial recovery actions began at 16:22 UTC, when key services on the affected Edge signalling SBC were restarted, restoring functionality for the majority of impacted users. A small number of users required an additional corrective action, and full service was restored for them at 16:50 UTC by temporarily redirecting their traffic to an alternative Edge to ensure continuity. The following day, all relevant services were comprehensively restarted to confirm stable and correct operation across the platform. **Mitigative Actions** * Strengthening maintenance procedures and post‑upgrade validation to prevent incomplete steps during routine operations. * Implementing enhanced monitoring to alert teams immediately if registration success rates drop to zero on any Edge.

Read the full incident report →

Started Feb 26, 2026, 10:21 AM UTC· resolved Mar 03, 2026, 04:41 PM UTC

1. investigating Feb 26, 2026, 10:21 AM UTC

   We are currently investigating an issue affecting ConnectMe in EU West. This is impacting a subset of users and includes login issues as well as inbound and outbound call failures 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

2. monitoring Feb 26, 2026, 10:23 AM UTC

   Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. 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.

3. resolved Mar 03, 2026, 04:41 PM UTC

   This incident has been resolved.

4. postmortem Mar 05, 2026, 10:42 AM UTC

   **Major Incident Category** Service Degradation **Post Mortem Owner** Ant Hurlock **Date Post Mortem Completed \(UTC\)** 04 Mar 2026, 17:30 **Incident Summary** On 26th February 2026, a small percentage of ConnectMe users in the EU West region experienced service degradation between 08:19 and 09:22 UTC. Affected users were connected to a single platform node and encountered varied symptoms, including blank screens after login and disruptions to calling and related functionality. Although the overall number of impacted users was limited, the disruption for those affected was significant. Engineers applied mitigation steps, and all services were fully restored and confirmed stable by 09:22 UTC. **Root Cause** The incident was triggered by a software fault within a core platform component. A planned update containing improvements and fixes for two related issues had not yet been deployed, meaning these enhancements were not available in the production environment. The first issue caused the affected platform node to become unresponsive, and the diagnostic information required to quickly identify the cause was insufficient. The upcoming update will introduce enhanced logging to provide the visibility needed to detect and analyse node deadlock scenarios in real time. The second issue involved the node’s health‑monitoring probe. A related software defect meant the probe could take significantly longer than expected to detect and recover from failures, extending the automated recovery window to as much as two hours. Although the platform is designed to self‑recover within this timeframe, in this case recovery did not occur until engineers intervened manually to restore service. **Incident Resolution** The issue was first detected by automated monitoring at 08:19 UTC, prompting immediate investigation by our engineering team. Initial recovery efforts were delayed due to an incorrect procedure, which terminated the unhealthy pod but left the health‑check waiting on internal conditions that were not relevant to this type of failure. As a result, the health‑check began a recovery cycle that could have taken up to two hours to complete. Engineers then intervened manually, restarting the affected component and restoring normal service for all impacted users at 09:22 UTC. Service stability was confirmed following this intervention. **Mitigative Actions** * Accelerating deployment of the planned software update. * Improving the speed and reliability of automatic recovery by resolving the issue that previously caused the health‑monitoring probe to delay self‑recovery by up to two hours. * Introducing enhanced logging to support faster diagnosis of node deadlock scenarios and progress towards a permanent fix. * Updating runbooks to provide clearer guidance for rapid recovery and validation of service restoration.

Read the full incident report →

Started Feb 14, 2026, 03:35 AM UTC· resolved Feb 14, 2026, 10:54 AM UTC

1. investigating Feb 14, 2026, 03:35 AM UTC

   We are currently investigating an issue affecting ConnectMe & SMP in the Nordics production environment. Users will be unable to log into these services. Additional services including CRM Connect, Teams Connect and Omnichannel are also showing service degradation. 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

2. investigating Feb 14, 2026, 03:57 AM UTC

   We are continuing to investigate this issue.

3. investigating Feb 14, 2026, 04:00 AM UTC

   We continue to investigate this incident in collaboration with our Platform team and are implementing measures to reduce user impact wherever possible. We will provide an additional update within the next 60 minutes. Thank you for your continued patience and understanding during this time. Dstny Support

4. investigating Feb 14, 2026, 04:51 AM UTC

   We continue to investigate this incident in conjunction with our Platform team. There has been no change in the current service impact, and mitigation activities remain in progress. The next update will be provided within the next 60 minutes. Thank you. Dstny Support

5. investigating Feb 14, 2026, 05:46 AM UTC

   Our teams continue to work on this incident with the highest priority. While service remains impacted and there has been no change in status, we are making progress in narrowing down the underlying cause and are actively exploring additional mitigation paths to restore stability as quickly as possible. We will provide a further update within the next 60 minutes. Dstny Support

6. monitoring Feb 14, 2026, 06:16 AM UTC

   Our Platform team has identified the root cause of the issue and implemented corrective measures to restore application services. 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.

7. resolved Feb 14, 2026, 10:54 AM UTC

   This incident has been resolved.

8. postmortem Mar 09, 2026, 03:05 PM UTC

   **Incident Summary** On 14th February 2026, a critical outage affected all users in the Nordics production environment. The authentication service became unavailable, resulting in a complete loss of access to all authentication‑dependent services including ConnectMe, SMP, and others. The incident began at 00:27 UTC and was resolved for end-users by 05:15 UTC. **Root Cause** The outage was caused by an unintended configuration that allowed a point‑in‑time recovery backup file to grow unexpectedly. This rapid growth consumed the storage allocated to the authentication database. Once the storage was exhausted, the database crashed, rendering the authentication service \(Keycloak\) unavailable. As a result, all dependent services relying on authentication were unable to process login operations, leading to a widespread service outage. **Incident Resolution** Service was restored by increasing the storage capacity for the authentication database and identifying that an automated cleanup process was rapidly consuming the new space. The authentication service was temporarily scaled down to halt the excessive data growth, and an index was added to improve the cleanup process. Once these steps were completed, the authentication service was brought back online and user access was restored at 05:15 UTC. Work to restore full database redundancy continued after user impact ended. **Mitigative Actions** * The team is reviewing whether point-in-time recovery should be implemented for the authentication database. * The recovery procedure for the database is being overhauled and comprehensively updated to ensure a faster and more effective response in future incidents. * Steps are being taken to confirm that the bastion server is fully isolated and dedicated to production, ensuring separation from development environments. * Ongoing investigation into periodic CPU and network spikes related to Keycloak database queries is underway.

Read the full incident report →

Started Dec 17, 2025, 04:35 PM UTC· resolved Dec 19, 2025, 01:22 PM UTC

1. investigating Dec 17, 2025, 04:35 PM UTC

   We are currently investigating a potential problem affecting ConnectMe. Impact: When muting a call during a conversation using ConnectMe, the mute function fails. The call appears muted in the UI, but audio remains active. This issue occurs when muting via the ConnectMe interface; muting via the headset itself is unaffected. The problem affects all regions and all users running the latest version (8.22.8) of the application. Our teams are actively working to identify the scope of the issue and will provide further updates as more information becomes available. Thank you for your patience as we work to address this matter. Dstny Support

2. identified Dec 18, 2025, 03:53 PM UTC

   We are proceeding with an emergency change across all regions to address the mute function issue in ConnectMe. Action Required: Users should refresh the web version of ConnectMe for the changes to take effect. For the desktop version, please restart the application if it was not fully closed. Thank you for your cooperation and patience as we work to resolve this matter. Dstny Support

3. monitoring Dec 18, 2025, 04:42 PM UTC

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

4. resolved Dec 19, 2025, 01:22 PM UTC

   We are pleased to confirm that the mute function problem in ConnectMe has been fully resolved in the production environment across all regions following the deployment of a permanent fix earlier this morning. All post-fix testing concluded that the issue is no longer present and has been successfully resolved. The same fix will be deployed into the UAT/Staging environment in all regions next week, permanently addressing this problem across all environments. Thank you for your patience and cooperation throughout this process. If you have any questions or concerns, please contact our Support team. Dstny Support

Read the full incident report →

Started Dec 16, 2025, 11:12 AM UTC· resolved Dec 17, 2025, 04:04 PM UTC

1. investigating Dec 16, 2025, 11:12 AM UTC

   We are currently investigating a potential incident affecting ConnectMe in the Nordics region. Impact: Suspected latency issues and intermittent disconnections from the server, resulting in no inbound or outbound calls. Our teams are actively working to identify the scope of the issue and 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

2. investigating Dec 16, 2025, 12:05 PM UTC

   We are currently investigating an issue affecting ConnectMe and SMP in the Nordics region. Impact: Users are experiencing timeout issues, latency, and disconnections on both products. The problem appears to be linked to high CPU utilisation. Our engineering team is actively working to put mitigations in place to restore service. 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

3. identified Dec 16, 2025, 01:02 PM UTC

   We are still actively mitigating the issue affecting ConnectMe and SMP in the Nordics region. While our engineering team continues to work on a full resolution, it is our expectation that customers should no longer be experiencing any further impact. If this changes, we will update immediately. However, if you encounter any issues whether intermittent or persistent, please raise them with Support urgently. Our next update will follow in one hour. Thank you for your continued patience. Dstny Support

4. identified Dec 16, 2025, 01:03 PM UTC

   We are writing to inform you that an issue occurred today affecting ConnectMe and SMP in the Nordics region. The impact has been mitigated, and we are satisfied that customers should not experience any further disruption. We will continue to monitor the situation for the next 24 hours. If you encounter any issues, whether intermittent or persistent, please contact our Support team immediately. Thank you for your understanding and patience during this time. Dstny Support

5. identified Dec 16, 2025, 02:07 PM UTC

   We are writing to inform you that an issue occurred today affecting ConnectMe and SMP in the Nordics region. The impact has been mitigated, and we are satisfied that customers should not experience any further disruption. We will continue to monitor the situation for the next 24 hours. If you encounter any issues, whether intermittent or persistent, please contact our Support team immediately. Thank you for your understanding and patience during this time. Dstny Support

6. resolved Dec 17, 2025, 04:04 PM UTC

   We are writing to inform you that the issue affecting ConnectMe and SMP in the Nordics region yesterday has been mitigated, and we are satisfied that customers should not experience any further disruption. We have completed 24 hours of monitoring, and the incident is now considered resolved. We initially committed to providing a detailed post-mortem report within 5 business days. However, due to the complexity of this incident and the upcoming Christmas leave period, we require additional time to complete a comprehensive analysis. This will ensure the root cause is fully understood and that suitable preventative actions are identified to avoid recurrence. We will share the report as soon as it is finalised and appreciate your patience as we work to deliver thorough insights and preventative measures. We sincerely apologise for any inconvenience caused and thank you for your understanding and support throughout this incident. If you have any immediate questions or concerns, please reach out to our Support team. Dstny Support

7. postmortem Jan 07, 2026, 11:23 AM UTC

   **Incident Summary** On 16th December 2025 between 10:35 and 12:56 UTC, users of ConnectMe and SMP services in the Nordics‑STO production environment experienced widespread connection failures. A sudden surge in user disconnections and reconnections created an unexpected spike in system load, particularly on WebRTC components and network nodes. Rate-limiting protocols were initiated but the volume overwhelmed the cluster and prevented it from self‑recovering. As more users attempted to reconnect, CPU usage increased further, slowing key components and preventing successful registration to the ConnectMe backend. The incident was resolved at 12:56 UTC following scaling actions, configuration adjustments, and the introduction of additional rate‑limiting measures. **Root Cause** The network experienced a high number of user disconnects and reconnection attempts within a very short period of time. Each reconnect triggered a resource‑intensive validation step on the backend. Because the number of configured endpoints per WebRTC component was higher than previously tested, this caused CPU usage to rapidly increase across several nodes. Due to a limitation in the rate-limiting protocols, the system accepted more reconnection attempts than it could handle, compounding the load and slowing down essential components. This created a feedback loop where users attempting to reconnect further increased CPU pressure, preventing the system from stabilising. **Incident Resolution** Service availability was immediately stabilised by redeploying WebRTC pods to clear outdated endpoint data, increasing CPU and memory allocations, and adding an extra service node to better distribute load. An emergency fix was also applied to remove a bottleneck and introduced stronger rate‑limiting to control the surge of reconnection attempts, while scaling additional WebRTC components to handle the increased traffic. These combined measures improved registration rates, reduced CPU pressure, and restored normal service by 12:56 UTC. **Mitigative Actions** * Strengthen WebRTC scalability and enforce effective rate‑limiting across all layers. * Reduce the number of endpoints per WebRTC pod based on updated performance testing and add proactive alerts for rapid endpoint growth. * Improve retry and rate‑limiting behaviour within ConnectMe and related APIs.

Read the full incident report →

Started Dec 01, 2025, 09:48 AM UTC· resolved Dec 03, 2025, 03:16 PM UTC

1. investigating Dec 01, 2025, 09:48 AM UTC

   We are currently investigating a potential major incident affecting ConnectMe in the EU West region, following internal alerts indicating possible latency within the system. Our teams are actively working to determine the scope of the issue, and we will provide updates every 60 minutes as more information becomes available. If your customers experience service issues this morning, please contact Support. Possible symptoms may include slow navigation within the ConnectMe client and login difficulties. Thank you for your patience while we work to resolve this matter. Dstny Support

2. investigating Dec 01, 2025, 10:38 AM UTC

   We have confirmed that the impact relates to latency issues affecting Dstny Core services, including the ConnectMe application. Our teams are continuing to investigate and troubleshoot the underlying cause. At present, latency on the platform appears to have returned to normal levels. We will continue to monitor the situation closely and provide the next update in 1 hour. Thank you for your patience and cooperation. Dstny Support

3. investigating Dec 01, 2025, 12:23 PM UTC

   Our teams are continuing to investigate and troubleshoot the underlying cause of the earlier latency issues affecting Dstny Core services, including the ConnectMe application. Latency continues to remain within normal levels at this time. We will provide the next update in 1 hour or sooner if there are any significant changes. Thank you for your patience and cooperation. Dstny Support

4. monitoring Dec 01, 2025, 01:40 PM UTC

   With this in mind, we are moving the incident into a monitoring state for the next 24 hours while investigations continue. As noted, there is no ongoing risk to customers, and we believe the issue has been mitigated. We will provide further updates if anything changes during the monitoring period. Thank you for your patience and cooperation. Dstny Support

5. investigating Dec 01, 2025, 02:09 PM UTC

   We have confirmed that the impact has returned, and our teams are actively investigating the issue. Further details will be shared as soon as they become available. Thank you for your patience and cooperation. Dstny Support

6. monitoring Dec 01, 2025, 03:33 PM UTC

   Latency has now stabilised, and we continue to closely monitor the situation. As part of our mitigation plan, we will be moving the affected organisation to an alternate service node later this evening. This action is designed to prevent further impact and will not cause any disruption to service. Thank you for your patience and understanding. Dstny Support

7. monitoring Dec 02, 2025, 04:54 PM UTC

   Latency remains stable, and we continue to monitor the situation closely. As part of our mitigation plan, the affected organisation was moved to an alternate service node yesterday evening. We are still investigating the incident in collaboration with our Platform team. While measures have been implemented to reduce the risk of recurrence, the root cause has not yet been confirmed. Therefore, the incident will remain in a monitoring state until the root cause is fully determined. We will provide the next update within 24 hours. Thank you for your continued patience and understanding.

8. monitoring Dec 03, 2025, 10:01 AM UTC

   We have now identified the root cause of the incident, and mitigation actions have been implemented to prevent any immediate risk of recurrence. However, the major incident will remain in a monitoring state while our engineering teams diligently work on implementing a permanent solution. Further updates will be provided once a permanent fix has been confirmed. We apologise for any inconvenience caused and appreciate your continued patience during this time. Dstny Support

9. resolved Dec 03, 2025, 03:16 PM UTC

   We are pleased to confirm that this major incident has now been fully resolved. Over the past 24 hours, we have closely monitored the situation and observed no recurrence or further impact. The root cause has been identified, and mitigation actions were implemented promptly to prevent any immediate risk of recurrence. Our engineering teams will deploy a permanent solution pending further investigation and development to ensure long-term stability and prevent future occurrences. To provide transparency, a detailed post-incident 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 do not hesitate to contact our support team. Thank you, Dstny Support

10. postmortem Jan 07, 2026, 11:24 AM UTC

    **Incident Summary** On 1st December 2025, between 08:55 and 21:00 UTC, users of ConnectMe and SMP services in the EU West region experienced significant latency, slow response times, degraded performance, and failed requests. Proactive monitoring detected high latency and responsiveness issues with widespread impact on all users, with authentication problems particularly affecting SMP. The incident was resolved at 21:00 UTC following account migration load-balancing activities carried out alongside the implementation of a permanent fix. **Root Cause** A latent software limitation within a Core system’s handling of large-scale bulk operations resulted in a database lock being held longer than expected. Under certain operational conditions, this lock reduced the system’s ability to process concurrent requests efficiently, leading to increased latency and degraded performance for ConnectMe and SMP services. Because the underlying constraint allowed one workload to temporarily consume disproportionate database resources, downstream systems experienced elevated contention. This created wider‑scale performance issues across multiple customers in the EU West region, beyond those directly associated with the originating Core environment. **Incident Resolution** Initial stabilisation was achieved through targeted failovers and controlled service restarts to reduce load and restore baseline performance. As part of the permanent remediation, the impacted workload was redistributed to an alternate node to eliminate immediate contention, and a hotfix was deployed to correct the underlying software limitation. These combined actions fully restored normal service operation and addressed the root cause to prevent recurrence. **Mitigative Actions** Optimising the Core system to better handle large-scale bulk operations and prevent prolonged database locks. Reviewing and improving bulk update processes to strengthen system resilience under heavy load. Reduce the risk of latency in a single Core system causing wider impact by implementing additional network hardening measures across affected services.

Read the full incident report →