SoundStack incident

Network Incident Affecting a Subset of Services

Critical Resolved View vendor source →

SoundStack experienced a critical incident on April 9, 2026 affecting Live365 Streaming and Login Services, lasting 1h 34m. The incident has been resolved; the full update timeline is below.

Started
Apr 09, 2026, 08:12 AM UTC
Resolved
Apr 09, 2026, 09:47 AM UTC
Duration
1h 34m
Detected by Pingoru
Apr 09, 2026, 08:12 AM UTC

Affected components

Live365 StreamingLogin Services

Update timeline

  1. investigating Apr 09, 2026, 08:12 AM UTC

    We are currently investigating a network-related incident affecting a subset of services. Our team is actively working to identify the root cause and restore full service as quickly as possible.

  2. investigating Apr 09, 2026, 08:15 AM UTC

    We are continuing to investigate this issue.

  3. monitoring Apr 09, 2026, 08:35 AM UTC

    A fix has been implemented and we are monitoring the results.

  4. resolved Apr 09, 2026, 09:47 AM UTC

    The incident affecting a subset of services has been resolved, and all impacted systems are now operating normally. Our team will continue monitoring the environment closely, and we will share a full Root Cause Analysis once it is completed.

  5. postmortem Apr 09, 2026, 04:34 PM UTC

    On April 9, 2026, between approximately 06:58 UTC and 08:43 UTC, a subset of services in the US-Central environment experienced connectivity issues. ## **What Happened** During routine maintenance activity within the US-Central environment, a network configuration issue caused a disruption to connectivity between parts of the Soundstack and Live365 platform and its control services. As a result, some services were unable to start or recover normally during the incident window. Both existing and new workloads were impacted during this time. Existing services experienced degraded behavior due to loss of connectivity, while new or restarting services could remain unavailable until communication was restored. ## **Resolution** Our engineering team identified the issue and implemented a temporary routing adjustment, followed by a DNS change at approximately 08:18 UTC to restore platform communication. Services began recovering immediately after this change, with most functionality restored by approximately 08:33 UTC. Full service recovery, including resolution of residual failures and verification of system stability, was completed by approximately 08:43 UTC. ## **Preventive Actions** To reduce the possibility of similar incidents in the future, we are implementing the following improvements: * Restricting unattended maintenance activity on critical infrastructure nodes * Upgrading core network failover components to versions with improved health monitoring and self-recovery capabilities * Reviewing recovery procedures to further reduce restoration time We apologize for the disruption and appreciate your patience while the issue was resolved.