GatewayAPI Incident History

1. resolvedOct 25 · 13:01 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.

Reported by GatewayAPI on their status page.

1. resolvedOct 22 · 14:42 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.

Reported by GatewayAPI on their status page.

1. resolvedOct 20 · 10:15 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.

Reported by GatewayAPI on their status page.

1. resolvedOct 9 · 15:22 UTC

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

Reported by GatewayAPI on their status page.

1. resolvedOct 8 · 10:06 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.

Reported by GatewayAPI on their status page.

1. postmortemSep 30 · 19:12 UTC

   Summary: Delayed message processing on GatewayAPI.eu - 29 September 2026

   On 29 September 2026, between 18:24 and 20:05 UTC (20:24–22:05 CEST), GatewayAPI.eu experienced a 101-minute delay in message processing. Our 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 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 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.

Reported by GatewayAPI on their status page.

1. ResolvedSep 29 · 20:27 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.

Reported by GatewayAPI on their status page.