GatewayAPI Outage History

Started Nov 02, 2026, 03:31 PM UTC· resolved Nov 02, 2026, 05:35 PM UTC

1. investigating Nov 02, 2026, 03:31 PM UTC

   We are investigating an issue affecting outgoing (MT) SMS. Messages may be delayed. Our team are working to identify the cause. We will post an update as soon as we have new information.

2. investigating Nov 02, 2026, 04:43 PM UTC

   We are still investigating the issue affecting outgoing (MT) and (MO) SMS traffic. Messages is still delayed. Our team is working to find the cause and restore normal delivery. We will post another update once we have more information.

3. investigating Nov 02, 2026, 05:01 PM UTC

   We are still working on the issue affecting outgoing (MT) SMS on gatewayapi.com. While the incident is ongoing, we recommend sending your SMS through our EU platform at https://gatewayapi.eu/, which is running normally.

4. monitoring Nov 02, 2026, 05:20 PM UTC

   We are seeing outgoing (MT) SMS traffic starting to recover. Messages queued during the incident are now being processed, so some customers may still see delays and late delivery reports for a while. We continue to monitor the situation. We will post another update once the queue is processed.

5. resolved Nov 02, 2026, 05:35 PM UTC

   Message processing on GatewayAPI.com is back to normal, and all queued messages have been delivered. We’re keeping a close eye on the platform. What happened From 16:02 CET (15:02 UTC) to about 18:15 CET, outbound messages from GatewayAPI.com were delayed. Our API was up the whole time and accepted every message sent to it. Some messages waited in our queue longer than usual before going out to the networks. Impact Only GatewayAPI.com customers were affected. Other GatewayAPI platforms were not. No messages were lost. Every accepted message was queued and delivered, some with a delay. No data was exposed or breached. This was a performance problem, not a security incident. What we’ve done We traced the problem to how our internal message-processing workers pick up messages from the queue. We changed that setting, and normal processing resumed right away. As a precaution, we’re running with extra processing capacity and have added more monitoring while we confirm the root cause. Next steps We’re still looking into the underlying cause, including a suspected problem in one of the software components our processing workers depend on. We’ll publish a full post-incident review here within 48 hours with the root cause and the steps we’re taking to stop this from happening again. We’re sorry for the disruption and thank you for your patience. If you have questions about specific messages, please contact our support team.

6. postmortem Nov 03, 2026, 03:24 PM UTC

   **Summary** On 2 November 2026, messages sent through [GatewayAPI.com](http://GatewayAPI.com) were delayed. After a period of slightly degraded processing, message processing stopped between 16:02 and 18:12 CET \(15:02–17:12 UTC\). Our API stayed available throughout and accepted every message. Accepted messages were queued and delivered once processing resumed. The backlog was cleared by 18:35 CET \(17:35 UTC\). **Impact** * Only [GatewayAPI.com](http://GatewayAPI.com) customers were affected. * No messages were lost. Every accepted message was delivered, some with a delay. * No data was exposed or breached. This was a processing failure, not a security incident. * Delivery reports and webhooks to customer endpoints were also delayed during this period. **Root cause** Our message-processing workers send requests to operators and other internal services using a third-party HTTP client library. A defect in that library's connection handling left the workers unable to assign new requests to open connections. **Resolution** We first ruled out our internal network and infrastructure. Restarts and a deployment rollback didn't help. At 18:10 CET \(17:10 UTC\) we lowered the number of tasks each worker takes on at once. Processing recovered within minutes, and the queued messages were delivered by 18:35 CET \(17:35 UTC\). **What we're doing to prevent it from happening again** * **Done:** Each worker now handles fewer tasks at a time, which makes it much less likely this fault happens again. * **Done:** We ran extra processing capacity while we investigated. We're now back to normal operations with automatic scaling, and the added monitoring remains in place. * **Done:** Alerts for unusually low message throughput now notify our on-call engineers directly, so we can respond sooner. * **Planned:** We'll evaluate and replace the affected HTTP client library. This was already on our roadmap, and we've now made it a priority. * **Planned:** We're building better diagnostic tools so our engineers can find the cause of an issue like this faster. This includes automated internal network checks and detailed logging that can be switched on when needed. We're sorry for the disruption. Reliable, timely delivery is the core of our service. If you have questions about specific messages, please contact our support team.

Read the full incident report →

Started Oct 25, 2026, 09:42 AM UTC· resolved Oct 25, 2026, 01:01 PM UTC

1. monitoring Oct 25, 2026, 09:42 AM UTC

   We are currently experiencing issues towards Telia Sweden. Delivery Reports (DLRs) may be delayed. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again.

2. resolved Oct 25, 2026, 01:01 PM UTC

   The issue towards Telia Sweden has been resolved. Delivery Reports (DLRs) are being returned as expected. Any delayed DLRs from the incident period should now have been delivered. If you still see missing or delayed DLRs for Telia Sweden, please contact our support team.

Read the full incident report →

Started Oct 22, 2026, 02:24 PM UTC· resolved Oct 22, 2026, 02:42 PM UTC

1. identified Oct 22, 2026, 02:24 PM UTC

   We are currently experiencing delays in delivery reports (DLRs) for messages sent to TDC Denmark. Message delivery is not affected. All messages are being delivered to recipients as normal, but the corresponding delivery reports may arrive later than usual. We are working with TDC to resolve the issue and will post an update as soon as we know more.

2. resolved Oct 22, 2026, 02:42 PM UTC

   This issue has been resolved. Delivery reports (DLRs) for messages sent to TDC Denmark are being delivered as normal again. All messages were delivered to recipients throughout the incident. Only the delivery reports and MO (incomming) messages were delayed. Thank you for your patience.

Read the full incident report →

Started Oct 20, 2026, 08:45 AM UTC· resolved Oct 20, 2026, 10:15 AM UTC

1. identified Oct 20, 2026, 08:45 AM UTC

   We are currently experiencing delays in delivery reports (DLRs) for messages sent to TDC Denmark. Message delivery is not affected. All messages are being delivered to recipients as normal, but the corresponding delivery reports may arrive later than usual. We are working with TDC to resolve the issue and will post an update as soon as we know more.

2. resolved Oct 20, 2026, 10:15 AM UTC

   This issue has been resolved. Delivery reports (DLRs) for messages sent to TDC Denmark are being delivered as normal again. All messages were delivered to recipients throughout the incident. Only the delivery reports and MO (incomming) messages were delayed. Thank you for your patience.

Read the full incident report →

Started Oct 09, 2026, 02:06 PM UTC· resolved Oct 09, 2026, 03:22 PM UTC

1. monitoring Oct 09, 2026, 02:06 PM UTC

   We are currently monitoring the Delivery Report delays towards ICE Norway. Users may experience a delay receiving the delivery reports. MT traffic is not affected. We will keep you updated.

2. resolved Oct 09, 2026, 03:22 PM UTC

   The Delivery Reports are back to normal towards ICE Norway. We will keep monitoring for good measure.

Read the full incident report →

Started Oct 08, 2026, 09:12 AM UTC· resolved Oct 08, 2026, 10:06 AM UTC

1. identified Oct 08, 2026, 09:12 AM UTC

   We are currently experiencing issues towards Tele2 Sweden. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved Oct 08, 2026, 10:06 AM UTC

   Traffic towards towards Tele2 Sweden is now back to normal. We will continue to monitor for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started Sep 29, 2026, 08:08 PM UTC· resolved Sep 29, 2026, 08:27 PM UTC

1. investigating Sep 29, 2026, 08:08 PM UTC

   We are experiencing issues with GatewayAPI.EU and are now investigating the root cause. We are currently working on resolving the issue. The .COM setup is still working as intended. We will keep you updated.

2. resolved Sep 29, 2026, 08:27 PM UTC

   We are seeing the services on GatewayAPI.EU fully operational again. The traffic and services will be monitored for good measure. Thank you for your patience and we apologize for the inconvenience caused by this.

3. postmortem Sep 30, 2026, 07:12 PM UTC

   **Summary: Delayed message processing on** [**GatewayAPI.eu**](http://GatewayAPI.eu) **- 29 September 2026** On 29 September 2026, between 18:24 and 20:05 UTC \(20:24–22:05 CEST\), [GatewayAPI.eu](http://GatewayAPI.eu) experienced a 101-minute delay in message processing. Our [GatewayAPI.com](http://GatewayAPI.com) platform was not affected. All inbound APIs, including the Mobile Messaging API, REST API and SMPP, remained available throughout the incident and continued to accept messages. However, accepted messages were queued rather than processed and sent. Delivery reports \(DLRs\) were delayed for the same reason. **No messages were lost.** Once processing was restored, all queued messages were delivered, with delays of up to 101 minutes. Customers do not need to resend any messages submitted during this period. We have detected a few messages that was delivered twice - this will only count one time on billed usage. **What happened** An unusually large bulk of messages was received and passed on to the internal service responsible for processing outgoing messages. Handling this volume required more memory than the service was allowed to use, so the platform automatically stopped it. When the service restarted, it picked up the same large backlog and was stopped again. This repeated in a loop, and during that time no messages could be processed. **Root cause** The memory allocated to our message-processing service was not sized to handle a bulk load of this magnitude. As a result, a single large burst of traffic was enough to put the service into a restart loop instead of being processed gradually. **Detection** We did not have automated alerting in place on [GatewayAPI.eu](http://GatewayAPI.eu) for this specific scenario, where our APIs keep accepting messages while processing stops. Because of this, the incident was not detected by our monitoring, and it took longer than it should have for us to respond. We take full responsibility for this gap. **Resolution** Our engineers identified the restart loop, increased the memory available to the message-processing service, and brought it back online. The service then worked through the queued backlog, and all pending messages and delivery reports were processed. **What we are doing to prevent this from happening again** * **Improved monitoring:** We have added an alert to [GatewayAPI.eu](http://GatewayAPI.eu) that triggers when processed traffic drops unexpectedly. * **Increased capacity:** The message-processing service now has a higher memory allocation, which reduces the risk of it being stopped under large bulk loads. * **Improved load handling \(in progress\):** We are already working on improvements to our internal message queueing, which will allow the platform to absorb similar spikes more gracefully in the future. We know how important timely delivery is to your business, and we apologise for the delay this caused. If you have questions about how this incident affected your account, please contact our support team.

Read the full incident report →

Started Sep 23, 2026, 03:56 AM UTC· resolved Sep 23, 2026, 04:27 AM UTC

1. investigating Sep 23, 2026, 03:56 AM UTC

   We are currently experiencing MT traffic issues on our REST API. This is only on our COM-setup. We are currently working to identify the root cause and solve the issue. We will keep you updated.

2. resolved Sep 23, 2026, 04:27 AM UTC

   This incident has been resolved. MT traffic on our REST API (COM-setup) is working as expected nagain. Thank you for your patience.

3. postmortem Sep 23, 2026, 01:38 PM UTC

   **Summary: Disruption to outgoing messages on** [**GatewayAPI.com**](http://GatewayAPI.com) **- 23 September 2026** On 23 September 2026, between 03:38 and 04:20 UTC \(05:38–06:20 CEST\), [GatewayAPI.com](http://GatewayAPI.com) experienced a 42-minute disruption on message handling. All public service APIs were affected, including the Mobile Messaging API and the REST API. Our initial status update referred only to the REST API; we apologise for under-reporting the scope. The Customer Dashboard and our EU platform \([GatewayAPI.eu](http://GatewayAPI.eu)\) were not affected. Message submissions during the incident were rejected by the API and needed to be resent. **What happened** Our platform runs on a managed Kubernetes service. During a routine automatic version upgrade performed by our cloud provider, an internal service that coordinates message processing failed to come back online. Each time it started, the platform's automated health check restarted it before startup had finished, leaving it in a restart loop. **Root cause** Kubernetes health checks \("probes"\) restart a service if a check exceeds its configured time limit. In earlier versions, this limit was not strictly enforced for our type of health check, which hid the fact that our limit was shorter than the service needs during startup. Our cloud provider had announced this change and paused automatic upgrades for clusters it identified as affected, but our cluster was not identified, so the upgrade went ahead. We take full responsibility for the configuration of our services. **Resolution** Our engineers analysed the startup requirements of the affected service and increased the health-check time limit with a safe buffer. The service then started normally, and message processing resumed. ‌ We know how important reliable messaging is to your business and apologise for the disruption. If you have questions about how this incident affected your account, please contact our support team.

Read the full incident report →

Started Sep 02, 2026, 07:59 PM UTC· resolved Sep 02, 2026, 08:06 PM UTC

1. identified Sep 02, 2026, 07:59 PM UTC

   We are currently experiencing delays towards Tele2 Sweden. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved Sep 02, 2026, 08:06 PM UTC

   Traffic towards towards Tele2 Sweden is now back to normal. We will continue to monitor for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started Aug 24, 2026, 09:01 AM UTC· resolved Aug 24, 2026, 01:48 PM UTC

1. identified Aug 24, 2026, 09:01 AM UTC

   We are currently monitoring the Delivery Report delays on our EU platform. Users may experience a delay receiving the delivery reports. MT traffic is not affected. We will keep you updated.

2. resolved Aug 24, 2026, 01:48 PM UTC

   The Delivery Report delays on our EU platform have now been resolved. All delayed delivery reports have been processed and are being delivered as normal. MT traffic was not affected at any point during the incident. We apologise for any inconvenience caused. If you are still seeing missing or delayed delivery reports, please contact our support team.

Read the full incident report →

Started Aug 19, 2026, 07:40 PM UTC· resolved Aug 19, 2026, 08:09 PM UTC

1. identified Aug 19, 2026, 07:40 PM UTC

   We are currently experiencing delays towards T-Mobile Germany. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved Aug 19, 2026, 08:09 PM UTC

   Traffic towards towards T-Mobile Germany is now back to normal. We will continue to monitor for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started Jul 10, 2026, 06:12 PM UTC· resolved Jul 10, 2026, 10:08 PM UTC

1. identified Jul 10, 2026, 06:12 PM UTC

   We are currently experiencing issues with delays towards Swisscom & Sunrise in Switzerland. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved Jul 10, 2026, 10:08 PM UTC

   Traffic is now back to normal towards Swisscom & Sunrise in Switzerland. We will continue to monitor for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started Jul 02, 2026, 07:36 AM UTC· resolved Jul 02, 2026, 08:35 AM UTC

1. identified Jul 02, 2026, 07:36 AM UTC

   We are currently seeing a lot of rejected and enroute with the SMS service of TDC Denmark. The traffic will be closely monitored whilst we expect an update. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. monitoring Jul 02, 2026, 07:49 AM UTC

   Traffic to TDC Denmark has recovered and rejected and enroute rates are back to normal. We are monitoring closely to confirm stability. Thank you for your patience, and we apologise for the inconvenience.

3. resolved Jul 02, 2026, 08:35 AM UTC

   The traffic towards TDC Denmark/Nuuday is fully operational. We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started Jun 19, 2026, 03:22 PM UTC· resolved Jun 19, 2026, 04:48 PM UTC

1. monitoring Jun 19, 2026, 03:22 PM UTC

   We are currently monitoring the Delivery Report issue reported by Telia Norway. Users may experience a delay receiving delivery reports on messages sent to Telia Norway recipients. Messages are delivered, it is only the status reports that are delayed.

2. resolved Jun 19, 2026, 04:48 PM UTC

   Delivery reports towards Telia Norway is now back to normal. We will keep monitoring for good measure. We are sorry for any inconveniences this may have caused.

Read the full incident report →

Started Jun 14, 2026, 10:41 AM UTC· resolved Jun 14, 2026, 11:14 AM UTC

1. identified Jun 14, 2026, 10:41 AM UTC

   We are seeing an unscheduled issue towards the GatewayAPI EU Dashboard and are working on resolving it. You may experience issues when trying to access the dashboard. We will keep you updated.

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

   We are continuing to work on the issue with GatewayAPI EU Dashboard. You may currently experience delays in both MT and MO traffic. We will keep you updated and we apologize for the inconvenience caused by this.

3. resolved Jun 14, 2026, 11:14 AM UTC

   The GatewayAPI EU Dashboard is up and running again. MT and MO traffic is back to normal. A Postmortem will follow. We will continue to monitor for good measure and we apologize for the inconvenience caused by this.

4. postmortem Jun 15, 2026, 10:33 AM UTC

   ## **GatewayAPI Incident Post-Mortem: Service Disruption on June 14, 2026** ‌ **Date of Incident:** June 14, 2026 **Duration:** 12:33 CEST – 13:05 CEST \(32 minutes\) **Services Impacted:** GatewayAPI EU SMS APIs & Customer Dashboard ‌ ### **Executive Summary** On June 14, 2026, between 12:33 CEST and 13:05 CEST, GatewayAPI experienced a service disruption that temporarily impacted our EU SMS APIs and the Customer Dashboard. The core issue originated from a localized network and infrastructure outage at our cloud provider, which unexpectedly isolated our main database cluster. While our core SMS services are architected to operate independently during database anomalies, the specific nature of this infrastructure failure triggered an unforeseen dependency that halted message-traffic processing. Our team intervened immediately, and services were fully restored within 32 minutes. ‌ ### **Root Cause Analysis** The disruption was initiated by a hardware and network-level incident within our cloud provider's infrastructure. This failure caused our primary database cluster to become unavailable. Although our message and SMS routing engine is designed with fail-safes to bypass database dependencies during outages, the unique state of this infrastructure failure prevented the seamless decoupling of these systems. This caused a temporary backlog, rendering both the Customer Dashboard and the EU SMS APIs unavailable during the affected window. ‌ ### **Actions Taken & Preventive Measures** We take platform reliability incredibly seriously and have already implemented several immediate improvements to ensure this specific scenario cannot happen again: * **Decoupling & Robustness Enhancements:** We have updated the message API and application routing mechanisms to ensure absolute independence from the primary database. In the event of a future database failure, core message and SMS routing will automatically fail back to decentralized, local mechanisms without interruption. * **Optimized Failover Routines:** We will refine and streamline our automated failover procedures to reduce the time it takes for secondary systems to assume control during infrastructure anomalies. * **Enhanced Monitoring & Alerting:** We will deploy additional high-fidelity alarms and alerting thresholds. This will grant our engineering team earlier visibility into underlying cloud provider infrastructure shifts before they impact user-facing services. ‌ **Our Commitment to You** We sincerely apologize for the disruption this caused to your operations. We are fully committed to providing a highly resilient business messaging platform, and we are using the insights gained from this incident to continuously harden our infrastructure. ‌ If you have any remaining questions regarding this incident, please feel free to reach out to our support team.

Read the full incident report →

Started May 29, 2026, 12:21 PM UTC· resolved May 29, 2026, 03:26 PM UTC

1. identified May 29, 2026, 12:21 PM UTC

   We are currently experiencing issues with Delays towards Finland. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved May 29, 2026, 03:26 PM UTC

   The traffic towards Finland is back to normal. We will keep monitoring for good measure. Thanks for your patience and sorry for any inconveniences this may have caused.

Read the full incident report →

Started May 26, 2026, 04:59 AM UTC· resolved May 26, 2026, 05:33 AM UTC

1. investigating May 26, 2026, 04:59 AM UTC

   We are experiencing issues with GatewayAPI.EU and are now investigating the root cause. All systems on GatewayAPI.EU are offline for the time being and we encourage you to stop all traffic on gatewayapi.eu until further notice. We are currently working on resolving the issue. The .COM setup is still working as intended. We will keep you updated.

2. resolved May 26, 2026, 05:33 AM UTC

   All systems are now back online for Gatewayapi.EU. We will keep monitoring for good measure. Thanks for your patience and understanding, we are sorry for any inconvenience this may have caused.

Read the full incident report →

Started May 19, 2026, 06:30 AM UTC· resolved May 19, 2026, 10:25 AM UTC

1. identified May 19, 2026, 06:30 AM UTC

   We are currently experiencing issues with delays towards Hi3G Denmark. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. monitoring May 19, 2026, 09:33 AM UTC

   The traffic towards Hi3G Denmark looks to be fully operational once again. We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

3. resolved May 19, 2026, 10:25 AM UTC

   The traffic towards Hi3G Denmark looks stable. This incident has been resolved. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started May 15, 2026, 03:09 PM UTC· resolved May 15, 2026, 04:25 PM UTC

1. identified May 15, 2026, 03:09 PM UTC

   We are currently experiencing issues towards Italy. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved May 15, 2026, 04:25 PM UTC

   The traffic towards Italy is back to normal. We will keep monitoring for good measure. Thanks for your patience and sorry for any inconveniences this may have caused.

Read the full incident report →

Started May 08, 2026, 08:17 AM UTC· resolved May 08, 2026, 10:19 AM UTC

1. identified May 08, 2026, 08:17 AM UTC

   We are currently experiencing issues with Delayed delivery reports towards ICE Norway. The traffic is being delivered at Normal rate. We will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved May 08, 2026, 10:19 AM UTC

   The traffic towards ICE Norway looks to be fully operational once again. We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started May 06, 2026, 03:31 AM UTC· resolved May 06, 2026, 04:40 AM UTC

1. investigating May 06, 2026, 03:31 AM UTC

   We are currently seeing some issues with the Traffic log. Users may experience issues when trying to access the Traffic log. We are currently working on resolving the issue. All traffic is still being delivered accordingly. We will keep you updated.

2. resolved May 06, 2026, 04:40 AM UTC

   The issue affecting the Traffic log has been resolved. Users should now be able to access the Traffic log again. Traffic delivery was unaffected throughout this incident.

Read the full incident report →

Started Apr 30, 2026, 01:57 PM UTC· resolved May 01, 2026, 08:25 AM UTC

1. identified Apr 30, 2026, 01:57 PM UTC

   We are currently experiencing issues with delayed delivery reports towards TDC/Nuuday All messages are getting delivered, it is only the delivery report that is delayed. We are monitoring the situation. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. monitoring Apr 30, 2026, 07:25 PM UTC

   We are continuing to see issues with delayed delivery reports towards TDC/Nuuday. And we are monitoring the situation. Traffic is still being delivered normally.

3. monitoring May 01, 2026, 07:05 AM UTC

   The traffic towards TDC Denmark/Nuuday looks to be fully operational once again. But we are still seeing previous messages stuck "Enroute". We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

4. resolved May 01, 2026, 08:25 AM UTC

   All traffic towards TDC/Nuuday is now working as intended again. Including timely delivery reports. Messages that have been submitted via GatewayAPI has been sent correctly. If you continue to experience any issues, please reach out to our support.

Read the full incident report →

Started Apr 27, 2026, 02:30 PM UTC· resolved Apr 27, 2026, 04:15 PM UTC

1. identified Apr 27, 2026, 02:30 PM UTC

   We are currently seeing some delays on messages towards Telia Norway. Messages are getting delivered despite the delays. We will monitor and update with any relevant information. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved Apr 27, 2026, 04:15 PM UTC

   All traffic towards Telia Norway seems to be flowing smoothly again. Incident is now considered resolved. If you experience any issues, contact our support for help.

Read the full incident report →

Started Apr 23, 2026, 07:25 PM UTC· resolved Apr 23, 2026, 07:43 PM UTC

1. investigating Apr 23, 2026, 07:25 PM UTC

   We are currently experiencing issues towards Telia/Norlys Denmark. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. resolved Apr 23, 2026, 07:43 PM UTC

   The traffic towards Telia/Norlys Denmark is fully operational once again. We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

Read the full incident report →

Started Apr 20, 2026, 05:08 PM UTC· resolved Apr 20, 2026, 06:02 PM UTC

1. investigating Apr 20, 2026, 05:08 PM UTC

   We are currently seeing issues with delays towards the Salt network in Switzerland. We will keep monitoring and update when there are any changes. We are sorry for any inconveniences this may cause.

2. resolved Apr 20, 2026, 06:02 PM UTC

   The traffic towards the Salt network in Switzerland is back to normal. We will keep monitoring for good measure. Thanks for your patience and sorry for any inconveniences this may have caused.

Read the full incident report →