Constant Time-Out Responses
closed
K
Kirk
Okay, this 504 Gateway time-out response from Postman is very important information!
What this means:
This is different from the ConnectionError you saw in Make earlier. That error meant Make itself gave up waiting after its own 60-second timeout.
This 504 Gateway time-out error comes directly from the server infrastructure between you and the final Hume AI service (specifically, it looks like Cloudflare, which Hume likely uses for security and performance).
A 504 means that a server acting as a gateway (Cloudflare) sent your request to the actual Hume AI TTS server (api.hume.ai) but the Hume AI server took too long to process your request and send a response back to the gateway. The gateway (Cloudflare) then gave up waiting and sent you this 504 error page.
Conclusion:
The problem isn't with Make's connection to Hume, nor is it likely an issue with network latency between Make and Hume anymore. The issue is that Hume AI's TTS generation process itself is taking too long to complete for that specific text payload, causing its own infrastructure (or the gateway in front of it) to time out.
This aligns with the "long wait" you experienced in Postman before getting the error.
What to do now:
Confirm Consistency: Does this 504 happen every single time you send that specific payload in Postman, or only sometimes? If it's consistent, it strongly suggests that particular text (perhaps its length or complexity) requires significant processing time by Hume.
Test with Simpler Text (Again): In Postman, try sending a request with a very short, simple sentence (e.g., {"text": "Hello there."} with the other necessary fields). Does this return quickly with a successful audio file? If yes, it reinforces the idea that the processing time is related to the complexity or length of the text in the failing requests.
Contact Hume AI Support (Most Important Step): This is now clearly an issue on the Hume AI side. You should contact their support team. Provide them with:
The exact JSON payload that caused the 504 error.
The Cloudflare Ray ID shown at the bottom of the error page: 939e8f51788b6713. This is critical for them to find the specific failed request in their logs.
The Timestamp from the error page: 2025-05-03 09:04:00 UTC.
Explain that you are sending requests to their /v0/tts endpoint and consistently receiving 504 Gateway Timeout errors for certain payloads, indicating their upstream processing is exceeding the gateway timeout limit.
Adjust Make Timeout (Limited Effect): You can still increase the timeout in your Make HTTP module (e.g., to 120 or even 180 seconds). However, be aware that if Hume's own gateway is timing out before your Make timeout is reached (as the 504 error suggests is happening), then increasing the Make timeout further won't help. The request will still fail with the 504 error passed back to Make. The fundamental issue of Hume's processing time needs to be addressed.
The key takeaway is that the bottleneck is the processing time within Hume AI's service for your specific request, leading to a server-side timeout (504). Contacting Hume support with the Ray ID is the most direct way to get this investigated.
Richard Marmorstein
Merged in a post:
Consistent and Continual Timeout "ConnectionError"
K
Kirk
I am continually getting a "ConnectionError" when trying to get a TTS audio file from HUME AI in the Make automation. The timeout is set to 60 seconds which is typically more than enough time for these short blocks of texts. What should I do?
Richard Marmorstein
closed
Closing this as this is ultimately a timeout issue from Make.com. Hume of course wants to make our TTS fast but the solution to timeouts will be to break the request up into smaller chunks that can consistently be completed in a smaller allotment of time than the timeout settings of your service.
Richard Marmorstein
@Kirk followed up on the related Discord thread, cross-posting here:
Update: figured out why Octave kept throwing 504s – fixed by client‑side sentence splitting
Hey team, quick follow‑up on the timeout saga:
🔍 Root cause
The synchronous /v0/tts endpoint has to finish synthesising every utterance before it can send the JSON back. We were handing it a single 700‑‑900‑character paragraph, so Octave needed ±50 s of planning + audio generation → the gateway’s ~45 s ceiling → 504 Gateway Timeout.
🛠 Fix we deployed in Make
ChatGPT “API‑formatter” step
• Takes the raw story JSON.
• Splits each paragraph value into per‑sentence chunks (. ? ! boundaries).
• Normalises curly quotes / em‑dashes / ellipses.
• Emits a ready‑to‑send JSON body with one utterance object per sentence.,
{
"format": { "type": "mp3" },
"split_utterances": false,
"utterances": [
{ "text": "Kirkie grabbed King Kong and held him tight.", "voice": {...} },
{ "text": "We have to save you!", "continuation": true },
{ "text": "The fire ants were making a long red line up the volcano.", "continuation": true }
],
"num_generations": 1
}
Make HTTP module
• Posts that JSON to https://api.hume.ai/v0/tts.
• Timeout left at 60 s (works fine now).
• One request per story page, no retries needed.,
🟢 Result
With ~150‑‑250‑char utterances the total synth time per page is ≈ 12–15 s, well inside both the gateway limit and our client timeout. Zero 504s in 50+ runs.
Bonus: The prompt is schema‑agnostic – if we add new keys (this_story_teaches_us, bonus_poem, etc.) they’re automatically split and appended in the right order, no extra code.
Hope this helps anyone else bumping into mysterious 504s! If you want the exact Make expressions or ChatGPT prompt, ping me.