A cURL timeout means the client stopped waiting. It does not establish whether IllyVoIP accepted a request before the connection was lost. First identify which part of the connection stalled, then choose recovery according to the operation rather than repeating every request automatically.
1. Separate transport errors from HTTP responses
Capture the cURL process exit code as well as the HTTP status. Without --fail or --fail-with-body, cURL can exit successfully after receiving an HTTP error response. Conversely, an HTTP status of 000 usually means no HTTP response code was obtained; it is not an IllyVoIP status code.
cURL exit code 28 indicates a timeout. A returned HTTP 504 is a response from a server or intermediary, and HTTP 429 is a rate-limit response. They need different investigation even if the user-facing application reports all of them as “request failed”.
2. Use a bounded read-only probe
Start without an API key on a read-only API URL. This checks connection timing without triggering a paid operation or placing credentials in a trace:
curl --silent --show-error --connect-timeout 10 --max-time 20 \
--output /dev/null \
--write-out 'http=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
https://api.illyvoip.com/api/v1/sip/identities
result=$?
printf 'curl_exit=%s\n' "$result"The values are seconds measured from the start, not independent durations to add together. For a fresh direct HTTPS connection, differences can help locate delay. Proxy use, connection reuse, redirects and protocol behavior can change their interpretation, so keep the actual network path with the result.
3. Locate the delay
| Item | Meaning or action |
|---|---|
| Name lookup is slow | Check resolver behavior and the exact hostname from the failing runtime. |
| Connect is slow or never completes | Check route, destination port, firewall and approved proxy reachability. |
| TLS stage stalls | Check handshake, trust configuration and any HTTPS inspection. |
| First byte is delayed | Distinguish server processing, upstream waiting and proxy response behavior. |
| Transfer stalls after a response begins | Inspect network interruption, response size and the application’s read deadline. |
Do not infer that the server is slow from total time alone. Compare a small number of probes from the same runtime and record their UTC times. Avoid repeated traffic that obscures a rate limit or creates a new load problem.
4. Choose deadlines for the actual operation
--connect-timeout bounds the connection phase, while --max-time bounds the whole transfer. The example’s 10 and 20 seconds are diagnostic choices, not an IllyVoIP service guarantee. Speech processing or a large export can have different expected durations from listing identities.
Set reviewed limits in the application and its reverse proxy or job worker. Making every deadline enormous hides failures and occupies workers. Making it shorter than normal processing can produce avoidable uncertain outcomes.
5. Recover without duplicating work
For a read, retry deliberately with bounded backoff after checking the failure and any Retry-After guidance. Keep pagination state and do not present a partial export as complete. For SMS, preserve the original payload and stored Idempotency-Key and follow the documented submission/status workflow.
For speech generation, purchases, call actions or other mutations, retain the original operation identity and reconcile the result before repeating. Do not assume that every endpoint accepts the SMS idempotency header or that a new key will recover the original request.
A timeout after a paid request may leave the outcome uncertain even when no response file exists. Record that uncertainty and use the operation’s documented history or Support path. Avoid --retry-all-errors or an outer shell loop around an arbitrary mutation.
6. Prepare a useful support report
Include the operation name, environment, UTC time, cURL exit code, HTTP status, safe timing values and a public operation reference if one was returned. State whether the request was read-only, accepted earlier or still uncertain. Note approved proxy use without disclosing its credentials.
Do not attach an unredacted verbose trace, API key or full customer payload. The goal is to identify the stalled phase and original operation, not to recreate a paid request merely to obtain another log.
Related guides and reference
cURL timing and deadlines. IllyVoIP API reference. Reviewed October 12, 2026. Examples are instructional: local checks do not establish a completed paid request, live third-party integration or production PBX acceptance.