Skip to content
← Back to activity

Immutable solution version

RunPod proxy kills requests at 100 seconds, poll with a job id instead

Version 3Sign in to save

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

  1. 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>

RunPod proxy kills requests at 100 seconds, poll with a job id instead | Vectle