InteleShare Status Page

Jul 20, 2026 · resolved Jul 20

**What Changed**  As part of the scheduled weekend maintenance window, the InteleShare infrastructure was switched to a more modern autoscaling and container-scheduling approach using Karpenter. Karpenter selects the most cost-efficient node/instance type for the current cluster load, replacing a prior approach that effectively over-provisioned compute without the team realizing it. The intent was more efficient and cost-effective use of cloud resources, faster scaling in response to traffic, and access to a wider variety of instance types to avoid AWS capacity constraints.  **What Failed**  InteleShare workload has relatively low CPU and memory requirements but handles a very high volume of concurrent network connections. Once the workload moved to Karpenter's "right-sized" scheduling, several instances of that workload's container were placed on smaller nodes than before \(moved from a 2XL instance down to an XL, roughly half the CPU\). The Linux kernel's connection-tracking table sizes its maximum entries based on the node's CPU and memory. Because the smaller nodes had a much lower ceiling, and because multiple instances of the high-connection workload were scheduled onto the same nodes, the combined connection count exceeded the conntrack limit once Monday-morning production load hit. Once the limit was reached, new connections on the affected nodes experienced delays or timeouts - and because the limit is enforced at the OS level, it affected other containers co-located on the same nodes as well.  **Why It Wasn't Caught Earlier**  The change had already been running in UAT and all other pre-production environments, which the team could observe before rollout, and it behaved correctly there. The issue only manifested under the connection volume and concurrency pattern of full U.S. production traffic - UAT volume is orders of magnitude lower and does not reproduce the same ordering/concurrency of requests. Simulating true production-scale concurrent-connection load in a lower environment is difficult and, at current test capacity, was not something the team could reasonably reproduce ahead of time.  **Impact**  Clients experienced degraded performance - delayed or timed-out connections - for approximately two to two and a half hours on Monday morning \(roughly 9:37 a.m. Eastern into the 10-11 a.m. hour\), concentrated around peak login/usage volume.  **Resolution**  The on-call platform engineer was paged automatically when the platform-wide Code Blue was triggered. The team identified the affected application tier and reverted that specific component back to the prior scheduling configuration; the rest of the Karpenter rollout \(roughly 85%\) remains in place. The revert was performed before the underlying root cause \(the conntrack ceiling\) was fully understood - root cause was confirmed afterward through investigation.

Feb 4, 2026 · resolved Feb 4

The incident has been fully resolved and service is back to normal levels. Our team will be conducting a root cause analysis and sharing as soon as possible. We will continue to monitor the situation to ensure there are no further issues.

Jun 9, 2025 · resolved Jun 9

**Issue Summary:** An automated update intended to modify a permissions policy encountered an unexpected failure. Instead of performing an in-place update, the process attempted to remove and then recreate the policy. While the removal was successful, the creation step failed, resulting in a missing policy until manual intervention restored it. **Impact:** During this period, newly launched instances and existing instances with expired cached permissions began experiencing errors when attempting to access necessary data. This led to intermittent issues in viewing and ingesting studies. **Resolution & Next Steps:** The issue was promptly identified and corrected through manual intervention. To prevent recurrence, we are actively reviewing and enhancing our processes to ensure that permissions policies are updated atomically and in-place. This improvement will strengthen system reliability and minimize the risk of disruption.

Apr 25, 2025 · resolved Apr 27

Between Friday, April 25 and Sunday, April 27, the InteleShare platform experienced degraded performance that affected both the user interface responsiveness and background processing operations. The issue has been fully resolved, and we have implemented both immediate fixes and planned long-term improvements to prevent similar incidents in the future.   The primary cause of this incident was a network bandwidth limitation on cloud-hosted infrastructure related to queued job processing, which became saturated when processing an unusually high volume of queued operations. This limitation caused latency to increase substantially, leading to: 1. Degraded user interface responsiveness 2. Significant delays in background processing operations Once we upgraded the infrastructure, processing capacity increased, allowing us to clear the backlog and restore normal operations.

Apr 24, 2025 · resolved Apr 24

On Thursday, April 24th, some InteleShare customer gateways were temporarily unable to connect to InteleShare due to third-party files remaining in use after a service stop was requested. To prevent this from happening in the future, the next Gateway release will include versioning of third-party libraries to avoid such conflicts. We appreciate your patience and understanding.

Is InteleShare down right now?

No — InteleShare is up. All systems operational as of Aug 19, 9:43 PM UTC.

What is InteleShare's current status?

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

How do I get alerted when InteleShare goes down?

Alert24 monitors InteleShare 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.