Questions › Guides

TradingView webhook timeout: why "request took too long" happens

Short answer: TradingView cancels a webhook request if your server takes longer than three seconds to answer (TradingView: webhooks). Separately, it resends when your server returns a 5xx error other than 504 (TradingView: webhook resubmission). The fix is to answer within 3 seconds and do the slow work your app does after you have replied.

TradingView's webhook documentation is short and strict: "If a remote server takes longer than three seconds to process a request, the request will be cancelled" (webhook docs). If your endpoint does real work before it answers, such as calling another API, writing to a database or waking a sleeping server, it is racing that clock.

What a timeout looks like

You see the alert in the Alerts log, so it fired. The delivery didn't succeed in time. Check the Webhook status column, which TradingView documents for monitoring delivery. Traders often report a "request took too long" message there, sometimes even when their server did receive the data and only answered late. That exact wording is reported by users, not quoted from TradingView's docs.

When TradingView resends, and when it cancels

If your server answers with HTTP 500–599 (except 504), TradingView sends the webhook again after 5 seconds. There can be a total of 3 such resends, so one trigger can be sent at most 4 times (webhook resubmission). Separately, a request that takes longer than about 3 seconds is cancelled (TradingView: webhooks).

TradingView --POST--> your server (needs a reply in ~3 s)
  reply 2xx in time .......... delivered
  reply 500-599 (not 504) .... resent after 5 s, max 3 resends
  no reply in ~3 s ........... cancelled
  reply 504 .................. not resent

Common causes

  1. Doing the work before replying. The slow work your app does, extra API calls or slow database writes run before the 200 goes back.
  2. Cold starts. Serverless functions or free-tier hosts that sleep can take seconds to wake up.
  3. A single busy worker. If one process is handling the previous alert, the next one waits.
  4. Restarts and deploys. While your app restarts, requests hang or are refused.
  5. Slow TLS or DNS on your side. Rare, but each step uses part of the same budget.
  6. Redirects. Use the final URL. TradingView's docs don't say whether webhooks follow redirects, and a redirect adds a round trip inside the 3-second limit.

How to fix it: answer first, work second

  1. Check the request is yours (a secret in the message body or an unguessable URL path; TradingView only lets you set a URL and a message).
  2. Put the alert in a durable queue.
  3. Return 200 first, then do the work.
  4. Let a background worker do the slow work and retries.
  5. Make the worker idempotent, so the same alert processed twice isn't acted on twice (see our duplicate alerts guide).
  6. Keep failed jobs somewhere you can see and resend them.

Test your endpoint's response time with our free Webhook Checker for TradingView. It sends one test request and tells you whether the answer came back within ~3 s, plus the status code, TLS and redirects. One test is a snapshot, so it won't catch a cold start that happens only after hours of quiet.

Or let HoldAlarms answer TradingView for you

Building that queue is the reason HoldAlarms exists. You paste your HoldAlarms link into the alert instead of your endpoint's address. We answer TradingView with HTTP 200 once the alert is queued, designed to reply fast, well before its ~3 second timeout, then deliver to your endpoint in the background. Your endpoint gets 10 seconds per attempt. If it fails, we retry up to 5 times, 2 to 60 seconds apart (permanent errors such as 401 or 403 aren't retried). Retries finish within about 3 minutes, or up to about 6 with Retry-After. After that the alert is parked in a dead-letter queue, and failure emails are grouped and capped at up to 10 a day.

Two honest limits: we add a hop, so HoldAlarms doesn't cut latency; and a delivered alert means your endpoint accepted it, not that your app finished processing it. Starter is €19/mo and Ops €49/mo.

Test your endpoint with the free Webhook Checker for TradingView Start your free trial: 300 alerts or 7 days, whichever comes first, no card

Questions

How long does TradingView wait for a webhook response?

About three seconds. TradingView's docs say requests that take longer are cancelled.

What happens when a webhook times out?

TradingView cancels a request that takes longer than about 3 seconds. Separately, it resends after HTTP 500–599 responses (except 504), after 5 seconds, with a total of 3 such resends.

Why does my server get the alert but TradingView says it failed?

Your server probably received the request but answered after the cutoff. Reply with 200 first and do the work afterwards.

Does HoldAlarms reduce latency?

No. HoldAlarms adds a hop, so each alert reaches your endpoint slightly later than it would directly. What it gives you is more time for your endpoint to answer and 5 retries if it doesn't. Alerts that still fail go to a dead-letter queue, and failure emails are grouped and capped at up to 10 a day.

Which ports can a TradingView webhook use?

Only 80 and 443. IPv6 isn't supported.

More guides

HoldAlarms is not affiliated with TradingView. TradingView is a trademark of TradingView, Inc.