Since 23 September 2026 ~09:00 UTC our Slides conversions have been failing. The requests do not return an error — they return nothing at all. The connection is established, the request is sent, and no response byte ever arrives until our client-side timeout fires.
We have isolated this to Aspose.Slides specifically. On the same TLS connection, with the same Bearer token, other products respond in well under a second.
Evidence: one run, one reused keep-alive connection to api.aspose.cloud
| Request | x-cluster | Result |
|---|---|---|
POST /connect/token |
cloud-02 | 200 in 0.21 s |
POST /v3.0/cells/convert/pdf |
cloud-01 | 200 in 0.61 s (valid PDF returned) |
PUT /v4.0/words/convert?format=pdf |
cloud-01 | 200 in 0.27 s (valid PDF returned) |
POST /v3.0/slides/convert/Pdf |
— | no response, timed out at 120 s (twice) |
POST /v3.0/slides/async/convert/Pdf |
— | no response, timed out at 120 s (twice) |
Raw client trace for a failing call (credentials redacted):
--> POST https://api.aspose.cloud/v3.0/slides/async/convert/Pdf
headers={ContentType: "multipart/form-data", Authorization: "Bearer <905 chars>"}
<-- elapsed=120.0s http_code=0 curl_return_code=:operation_timedout timed_out=true
curl_times={namelookup: 0.000026, connect: 0.000026, appconnect: 0.000026,
starttransfer: 0.000152, total: 120.000652}
response_headers={}
response_body=""
And a succeeding call in the same process moments later:
--> POST https://api.aspose.cloud/v3.0/cells/convert/pdf
<-- elapsed=0.61s http_code=200 curl_return_code=:ok
response_headers={"date"=>"Thu, 24 Sep 2026 08:37:08 GMT",
"content-type"=>"application/json; charset=utf-8",
"content-length"=>"171464",
"x-cluster"=>"cloud-01", "x-lb"=>"TLR"}
Two points we would highlight:
namelookup == connect == appconnect == 26 microsecondson the failing request. There was no DNS lookup, no TCP handshake and no TLS negotiation — libcurl reused the pooled connection that had just served/connect/tokenwith a 200. So the transport is demonstrably healthy; the request reaches you and nothing comes back.- Empty response headers and empty body. Not a 4xx, not a 5xx, not a partial response — zero bytes. We therefore have no request id to give you, because no response was ever produced.
Timeline
- 23 Sep 2026, ~09:00 UTC —
/v3.0/slides/async/convert/Pdfbegins timing out on every attempt. It has failed continuously since, on every run, for over 24 hours. - 24 Sep 2026, ~08:10 UTC —
/v3.0/slides/convert/Pdf(sync) still succeeded from one of our networks (~3 s). - 24 Sep 2026, 08:31–08:37 UTC — from a different network of ours, both the sync and async Slides endpoints return nothing, while Cells and Words from that same host succeed in under a second.
The path-dependence matches what your team described on 21 September in Aspose.Cells Cloud conversion to XLSM repeatedly times out after approximately 100 seconds: “some areas are experiencing timeouts, others are functioning normally” — which was ultimately resolved as “a malfunction in a specific Ingress”. We suspect the same class of problem, now on the Slides route.
We also reported this exact endpoint a year ago in Requests to v3.0/slides/async/convert/Pdf Are Timing Out, which received only an automated reply and was never investigated.
Request details
- Endpoints:
POST /v3.0/slides/convert/PdfandPOST /v3.0/slides/async/convert/Pdf - Body:
multipart/form-data, singledocumentpart, a small.pptx - The same file converts successfully through
/v3.0/slides/convert/Pdfin ~3 s whenever Slides is reachable, so this is not file-specific, size-related or an encoding problem - Client: direct HTTPS calls via libcurl (Typhoeus), not an SDK
- Auth: client-credentials token from
/connect/token, which succeeds in ~0.2 s every time - Note the async endpoint is a queue submission that should return
201with an operation id almost immediately — it performs no conversion — so a 120 s silence there cannot be explained by processing time
Happy to supply a sample file, further traces, or run any specific request you would like us to test. Please let us know the source IP range you need and we can provide it.