Experiencing issues with REST API on GatewayAPI.com

Update timeline

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.