Aspose.Slides Cloud returns no response at all

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:

  1. namelookup == connect == appconnect == 26 microseconds on 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/token with a 200. So the transport is demonstrably healthy; the request reaches you and nothing comes back.
  2. 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/Pdf begins 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/Pdf and POST /v3.0/slides/async/convert/Pdf
  • Body: multipart/form-data, single document part, a small .pptx
  • The same file converts successfully through /v3.0/slides/convert/Pdf in ~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 201 with 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.