The Things Industries Status Page

Jul 9, 2026 · resolved Jul 9

## Summary On 9 Jul 2026 , it was reported that some The Things Indoor Gateway Pro \(TTIG Pro\) gateways lost connection to the LNS for some of the tenants in EU2 region. This was triggered by certificate renewal issue. Once the remediation was in place, the affected gateways started reconnecting. ## Impact * Some gateways got disconnected for some of the tenants in EU2 region. * The number of connected gateways kept declining gradually. * Eventually, once the fix was in place, the affected gateways have reconnected and service has recovered without intervention. ## Root Cause The Let's Encrypt R12 certificate serving port `8889` expired on `Jul 8 2026 at 05:54 UTC`. This port is used exclusively by TTIG Pro gateways for their WebSocket connection to the LNS. Certbot had already renewed the certificate before expiry and stored the new YR-signed certificate in the `proxy_tls` secret in AWS Secrets Manager. However, the secret was not synced by the GatewayProxy \(Envoy\) service. As a result, Envoy continued to serve the expired R12 certificate from memory, causing all TTIG Pro TLS handshakes to fail with certificate verification error. The same expired-cert condition was present on AU1 and AS1 \(no TTIG Pro gateways in those regions, so no customer impact\) and was approaching on NAM1 \(cert expiring Jul 14\). ## Resolution The fix was applied by restarting the GatewayProxy ECS task on each affected cluster, which forced Envoy to re-read the `proxy_tls` secret from Secrets Manager on startup and load the already-renewed YR certificate. ## Prevention / Long-term improvements Investigate why the renewed certificate was not synchronized to Envoy and implement a permanent fix to ensure certificate updates are automatically reloaded before certificate expiry. Additionally, improve monitoring and alerting to detect certificate synchronization issues before they can impact customer traffic.

May 6, 2026 · resolved May 6

This incident has been resolved.

Mar 23, 2026 · resolved Mar 23

## Summary On March 23, 2026, during a scheduled maintenance window, the Gateway Server \(GS\) component in the NAM1 region was accidentally restarted, causing gateways to disconnect in a similar pattern to the March 3 incident. The development team took the opportunity to roll out a fix that had been planned for the next maintenance window. The fix resolved the reconnection issue and gateways are now reconnecting within several minutes. ## Impact Some gateways got disconnected for some of the tenants in the NAM1 region following an accidental Gateway Server restart during a maintenance window. ## Root Cause The incident was triggered by an accidental restart of the Gateway Server component in NAM1 during a scheduled maintenance window, causing gateways to disconnect in the same pattern observed during the March 3 incident — where simultaneous reconnects under high server load led to premature connection drops due to insufficient timeout and cache configurations. ## Resolution The development team used the opportunity to roll out a fix ahead of its planned release date. The deployed fix resolved the reconnection bottleneck, and affected gateways are now reconnecting within several minutes. No customer action is required. ## Prevention / Action items ### Process improvements Procedures around component restarts during maintenance windows will be reviewed to prevent accidental restarts of production-critical components such as the Gateway Server. ### Infrastructure improvements — already applied The fix rolled out during this incident addresses the reconnection performance issues identified in the March 3 post-mortem. Gateway Server instances in NAM1 are now able to handle mass reconnect scenarios significantly more efficiently, with reconnection times reduced to within several minutes.

Mar 3, 2026 · resolved Mar 5

## Summary On Mar 3, 2026 , it was reported that some gateways lost connection to the LNS for some of the tenants in NAM1 region. This was triggered by an AWS update procedure which has affected the Gateway Server component. Although the affected gateways reconnected eventually, it took longer than expected \(8 hours for some tenants\). ## Impact * Some gateways got disconnected for some of the tenants in NAM1 region. * Three Gateway Server instances restarted during the incident, disconnecting a large number of gateways which failed to immediately reconnect to remaining active instances. * The number of connected gateways kept declining gradually. * Eventually, the affected gateways have reconnected and service has recovered without intervention. ## Root Cause The incident was triggered by an AWS infrastructure event \(task retirement\), which caused several Gateway Server instances in NAM1 to undergo a rolling restart. As instances restarted one by one, gateways began disconnecting gradually. Since the restart was rolling rather than simultaneous, some gateways maintained their connection to instances that remained active throughout the event. The root cause of the prolonged recovery, however, was a short connection timeout configured on some gateways. With a large number of gateways attempting to reconnect simultaneously, the Gateway Server was operating under unusually high load — and the short timeout was insufficient under these conditions, causing connections to close prematurely before they could be fully established. This cycle repeated until the restarted instances completed their post-restart operations — at which point server load normalised and Gateway Server caches became available, significantly speeding up the connection process for the remaining disconnected gateways until service was fully restored. In short: the AWS infrastructure event triggered the affected gateways disconnects, but the timeout misconfiguration is what made the recovery take up to 8 hours. ## Resolution There was no manual intervention to resolve this incident. The affected gateways reconnected automatically after the downtime. ## Prevention / Long-term improvements ### Proactive outreach to affected tenant owners regarding gateway connection timeout A minimum 60-second timeout is necessary for reliable connection establishment under high server load conditions. We will be reaching out to affected tenant owners, recommending that the `TC_TIMEOUT` setting in their Basic Station configuration is set to at least the default value of `60s`. This change will help prevent premature connection drops during periods of elevated reconnect activity. ### Documentation improvements Existing documentation will be improved to specifically address recommendations for longer `TC_TIMEOUT` setting of the Basic Station configuration. ### Infrastructure improvements Our Cloud infrastructure configuration will be improved to reduce and accommodate higher instance load post-restart.

Jan 9, 2026 · resolved Jan 9

The incident has been resolved. The Things Indoor Gateway Pro gateways are reconnecting. This may take some additional time due to reconnect backoffs.

Is The Things Industries down right now?

No — The Things Industries is up. All systems operational as of Jul 13, 11:49 PM UTC.

What is The Things Industries's current status?

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

How do I get alerted when The Things Industries goes down?

Alert24 monitors The Things Industries 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.