GatewayAPI experienced a minor incident on September 29, 2026 affecting MT (Outgoing) SMS - Europe and API - Europe and 1 more component, lasting 18m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- 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.
- 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.
- 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.