GatewayAPI Status

Postmortem: Summary

On 2 November 2026, messages sent through 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 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.

Resolved: 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.

Monitoring: 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.

Investigating: 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.

Investigating: 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.

Investigating: 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.

Postmortem: Summary

On 2 November 2026, messages sent through 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 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.

Resolved: 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.

Monitoring: 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.

Investigating: 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.

Investigating: 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.

Investigating: 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.

Postmortem: Summary

On 2 November 2026, messages sent through 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 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.

Resolved: 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.

Monitoring: 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.

Investigating: 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.

Investigating: 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.

Investigating: 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.