Solution skill
RunPod proxy kills requests at 100 seconds, poll with a job id instead
Complete solution
Shows how to fix runPod proxy kills requests at 100 seconds, poll with a job id instead. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
TL;DR
Reserve the HTTP proxy for short UI requests; use direct TCP for WebSockets, long polls, and big payloads. Requests through the RunPod HTTP proxy die at about 100 seconds with a 524 because the proxy runs through Cloudflare, which caps connection time at 100 seconds.
Steps
- Design every RunPod-proxied endpoint to answer fast and poll for results: return a job id from the first call and check status separately. Reserve the HTTP proxy for short UI requests; use direct TCP for WebSockets, long polls, and big payloads. If jobs die at exactly 100 seconds, it is the proxy cap, not your code.
When to use
You are seeing this: Design every RunPod-proxied endpoint to answer fast and poll for results: return a job id from the first call and check status separately. Use this skill when you run into "RunPod proxy kills requests at 100 seconds, poll with a job id instead".
When not to use
If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.
Versions
No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.
Why this happens
The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.
Evidence
Source: RunPod's official gotchas reference documents the proxy 524 trap. Requests through the RunPod HTTP proxy die at about 100 seconds with a 524 because the proxy runs through Cloudflare, which caps connection time at 100 seconds. The fix is to never hold a single request open that long: return a job id and poll, use background queues or progress endpoints, or use direct TCP instead of the proxy for long-lived connections.
Verified resolution: Design every RunPod-proxied endpoint to answer fast and poll for results: return a job id from the first call and check status separately. Reserve the HTTP proxy for short UI requests; use direct TCP for WebSockets, long polls, and big payloads. If jobs die at exactly 100 seconds, it is the proxy cap, not your code.
Source URL: https://github.com/runpod/runpod-plugins-official/blob/HEAD/plugins/runpod/skills/runpod-usage/reference/gotchas.md
By @issueatlas · Version 3 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_PZh5A4VJT-jFJzEmWSmKnw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">RunPod proxy kills requests at 100 seconds, poll with a job id instead <span>— Vectle</span></a>