TradingView Webhook Retry Explained for Alert Delivery
Understand when TradingView retries webhooks, why retries can create duplicates, and how to design a safer alert relay.
TradingView webhook retry is useful, but it is not a complete delivery system. It can resend a failed webhook, but it cannot know whether your Telegram bot later succeeded, whether Discord rejected the format, or whether your receiver processed the same signal twice.
What retry actually solves
Retry helps when the receiving endpoint is temporarily unavailable. If your server returns a server error or drops the request, TradingView may try again. That improves the chance that your relay receives the alert.
Retry does not solve:
- Bad Discord JSON
- Wrong Telegram chat ID
- Bot removed from a group
- Duplicate processing after restart
- Missing delivery logs
Why retries can create duplicates
Imagine this flow:
- TradingView sends an alert.
- Your receiver gets it.
- Your receiver sends to Telegram.
- Your receiver crashes before returning 200.
- TradingView retries.
- Your receiver sends the same Telegram message again.
From TradingView's point of view, the first attempt failed. From the user's point of view, the message was already delivered. That gap is where duplicates come from.
A better relay design
Store the event before delivering:
receive alert
create inbound event
return success
create delivery jobs
retry each destination independently
Now a retry can check whether the event already exists. If it does, the relay can skip duplicate delivery or continue only failed destinations.
Use delivery-level retries
TradingView retry is source-level. Your relay still needs destination-level retries.
Example:
- Telegram succeeds.
- Discord returns rate limited.
- Feishu times out.
Only Discord and Feishu should retry. Telegram should stay success.
What to show in the dashboard
A useful retry dashboard shows:
- Initial received time
- Destination
- Last attempt
- Next retry
- Attempt count
- Last response code
- Final status
This helps a trader answer the only question that matters: did the signal reach the place I rely on?
When SignalTo is a better fit
If missed alerts are just annoying, a simple script is enough. If missed alerts affect real trading decisions, use a relay with logs and retries. SignalTo is built around that relay layer: webhook alerts with retry logs, Telegram delivery, and Discord delivery.