GatewayAPI Status Page

Oct 9, 2026 · resolved Oct 9

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

Oct 8, 2026 · resolved Oct 8

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.

Sep 29, 2026 · resolved Sep 29

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

Sep 23, 2026 · resolved Sep 23

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

Sep 2, 2026 · resolved Sep 2

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.

Is GatewayAPI down right now?

No — GatewayAPI is up. All systems operational as of Oct 12, 4:50 AM UTC.

What is GatewayAPI's current status?

GatewayAPI: All Systems Operational. Alert24 checks GatewayAPI's status page continuously and can notify you the moment it changes.

How do I get alerted when GatewayAPI goes down?

Alert24 monitors GatewayAPI and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.