I’ve been conducting a detailed evaluation of WellSaid Labs’ operational costs for our internal FinOps reporting, which involves batch-processing a substantial volume of generated audio files for archival and analysis. Over the past several weeks, I have encountered a persistent and reproducible issue with the platform’s audio download functionality that appears to be tied directly to file duration and, by extension, file size.
When attempting to download synthesized speech files exceeding approximately 10 minutes in length (which, at their standard high-quality format, translates to file sizes north of 8-9 MB), the download request consistently times out. This occurs both via the web interface and when using the API endpoint programmatically. The behavior is not intermittent; it is a deterministic failure for large files, while smaller files download without incident.
My initial troubleshooting, from an infrastructure perspective, ruled out local network constraints. I’ve replicated the failure across different networks and with direct command-line tools. The timeout occurs server-side, well before a transfer would be impacted by client-side bandwidth. This leads me to a few hypotheses about the underlying cause, which I’m detailing here to see if others have corroborating data or have discovered workarounds:
* **Service Endpoint Configuration:** The download service may have an improperly configured (or overly aggressive) request timeout or idle timeout setting on its load balancer or application server, which is not sufficient for the transfer of larger payloads.
* **Proxied Transfer Limits:** There might be an intermediary proxy or gateway (e.g., an API Gateway service) enforcing a maximum execution time for the download request handler, which is exceeded during the buffering and transmission of a larger audio stream.
* **Cold Start Latency:** If the download service is built on a serverless architecture (which would align with modern cloud practices), the generation of a pre-signed URL or the assembly of the file stream could be subject to cold starts. For large files, the combined time of cold start initialization plus stream preparation might exceed a fixed timeout threshold.
Has anyone else performing bulk exports or working with longer narrative audio segments experienced this specific timeout pattern? More importantly, has anyone engaged with WellSaid Labs support and received a technical explanation or a mitigation? A temporary workaround I’ve been forced to adopt is segmenting my long-form scripts into sub-10 minute chunks, but this introduces operational overhead and complicates our asset management.
From a cost-optimization standpoint, this is concerning. It represents a processing barrier that forces inefficient workflow design and could potentially lead to increased costs if we are compelled to implement additional orchestration logic or error-handling routines to manage these failures programmatically.
-- Liam
Always check the data transfer costs.
Yeah, that's a classic case of someone configuring their load balancer or API gateway timeout with the happy path in mind and forgetting that larger objects exist. Eight or nine megabytes isn't even that big - their timeout is probably set to something absurdly low, like 30 seconds, which wouldn't account for any network hiccup or a client with slower than gigabit speed.
If you're hitting this via the API too, I'd try to see if you can spot any headers in the response that give away their stack. A common culprit is an NGINX or ALB sitting in front of their application servers with a default `proxy_read_timeout` that's too aggressive. The fact it's deterministic means it's almost certainly a hard-coded limit on their end, not some transient resource exhaustion.
Have you tried a ranged request, just to see if you can get the first byte? Sometimes you can trick these setups by asking for chunks.
keep it simple
You're right that it's likely a hard limit in their transport layer. The 8-9 MB threshold is a strong clue. If we assume a typical default `proxy_read_timeout` of 60 seconds and a reasonable average download speed of 1.5 Mbps for a client, the math lines up almost exactly to that file size cap. It's a textbook oversight.
Ranged requests are a clever diagnostic. If they succeed, it confirms the issue is downstream of the application logic, likely at the proxy or CDN level. For a workaround, you could script a series of range requests to reassemble the file, though that's far from ideal.
Beyond NGINX or ALB settings, I've also seen this happen when a WAF or API management layer has a low "maximum allowed response size" configured, which can truncate or time out the transfer. The response headers might reveal something like `x-aws-region` or `server: envoy`.