Status: Resolved
If you noticed calls taking longer than usual to process between 10 and 14 August 2026, that's now fully resolved. The cause was an infrastructure fault that reduced our systems' ability to reliably make certain outbound connections. We fixed the affected infrastructure, confirmed there was no recurrence and are putting further safeguards in place. No customer data was affected at any point.
Between 10 and 14 August 2026, some calls took longer than usual to complete processing, meaning results such as transcripts or alerts were delayed rather than lost. At no point was any customer data lost, corrupted or exposed; the issue affected processing speed, not data integrity.
10 August: Customers first reported slower-than-usual call processing.
11 August, 07:58: Incident formally declared and investigation began.
12 August: The scale of the issue became clearer as background processing backlogs grew, and severity was raised accordingly. Investigation traced the fault to outbound network connections from our infrastructure being exhausted.
12 August (later): The affected network infrastructure was restarted and reconfigured to stop connections building up again. Processing began recovering shortly after.
13 August: Backlogs cleared and systems were confirmed stable through continued monitoring.
14 August, 13:46: Incident closed after confirming no recurrence.
Our platform routes outbound network connections, including those used for LLM-driven processing tasks such as alerts and scorecards, through a shared pool of network gateways. Some of these LLM-driven tasks are longer-running than typical requests, and the connections they opened were being held open for longer than necessary once a task finished. Over time, this caused the connection-tracking capacity on the shared gateways to fill up. Once that capacity was reached, new outbound connections, including ones needed for routine page loads, deployments and background job processing, began being dropped or delayed.
This meant the fault wasn't isolated to one feature: anything depending on an outbound connection through the affected gateways could be affected, which is why the impact showed up as both slow page loads and delayed call processing.
We restarted the affected network infrastructure to immediately clear the backlog, and reduced how long idle outbound connections are held open before being released, so the same build-up is far less likely to recur. We monitored connection levels and processing queues closely for several days afterwards before confirming the incident was fully resolved with no recurrence.
We're reworking how LLM-driven processing tasks make their outbound connections, so they no longer depend on the same shared gateway pool as core application traffic. We're also adding direct monitoring of outbound connection capacity, so a similar build-up is caught automatically rather than depending on customer or internal reports, and separating how time-sensitive background work is processed from longer-running analytical work, so one can't delay the other.
If a specific conversation seemed affected during this period, let support@voyc.ai know and we'll check it for you directly.
