TradingView to your endpoint: direct vs via HoldAlarms
Short answer: Going direct is fine if your endpoint always answers within 3 seconds and never goes down. TradingView cancels requests that take longer than about 3 seconds (TradingView: webhooks); if your endpoint answers HTTP 500–599 (except 504), TradingView sends it again after 5 seconds, with a total of 3 such resends (TradingView: webhook resubmission). Via HoldAlarms, your endpoint gets 10 seconds per attempt, 5 retries and a dead-letter queue, with failure emails grouped and capped at up to 10 a day, at the cost of one extra hop.
You can point a TradingView webhook straight at your endpoint, or point it at HoldAlarms and let HoldAlarms pass it on. Both work. This page explains when each one makes sense.
How direct works
TradingView sends a POST to your URL when the alert fires. It waits about 3 seconds for an answer and cancels the request if it doesn't get one (TradingView: webhooks). It resends when your server returns a 5xx error (except 504), after 5 seconds, with a total of 3 such resends (TradingView: webhook resends).
How via HoldAlarms works
HoldAlarms answers TradingView straight away, queues the alert and forwards it to your endpoint. Your endpoint has 10 seconds per attempt to answer, and any 2xx counts as accepted. If it doesn't accept, HoldAlarms retries up to 5 times, 2 to 60 seconds apart (permanent errors such as 400, 401 or 403 aren't retried). Retries finish within about 3 minutes, or up to about 6 with Retry-After. If it still fails, the alert is parked in a dead-letter queue with the reason it failed, failure emails are grouped and capped at up to 10 a day, and you can email support and we'll look at it with you (HoldAlarms FAQ).
Side by side
Good Partial Bad
| Feature | TradingView direct | HoldAlarms |
|---|---|---|
| Time your endpoint gets | 3 s, cancelled | 10 s per try |
| Endpoint timeout | Cancelled at ~3 s | 5 retries |
| Endpoint 5xx (error) | Max 3 resends | 5 retries |
| Endpoint down | Not retried by TradingView | Kept in DLQ |
| Fail email | No | Up to 10/day |
| Silence email | No | Via heartbeat |
| Hops | One | Two |
Notes on the table
- Time your endpoint has to answer. Direct: About 3 s (TradingView's limit). Via HoldAlarms: 10 s per attempt (HoldAlarms answers TradingView). HoldAlarms answers TradingView as soon as the alert is queued, designed to reply fast, well before its ~3-second timeout.
- Endpoint is slow or times out. Direct: TradingView cancels the request after about 3 s. Via HoldAlarms: Retried up to 5 times, 2 to 60 seconds apart. Retries finish within about 3 minutes, or up to about 6 with Retry-After.
- Endpoint returns a 5xx error. Direct: TradingView resends after 5 s, max 3 resends (not on 504). Via HoldAlarms: Retried up to 5 times, 2 to 60 seconds apart. Retries finish within about 3 minutes, or up to about 6 with Retry-After.
- Endpoint is down for longer. Direct: TradingView documents resends for 5xx errors (not 504), at most 3. Via HoldAlarms: Parked in a dead-letter queue; email support and we'll look at it with you.
- Email when a delivery fails. Direct: No. Via HoldAlarms: Yes. If delivery still fails after the retries, or straight away on a permanent error, the alert goes to the dead-letter queue and we send a failure email ("HoldAlarms: alert not delivered to <destination>"). Failure emails are grouped and capped at up to 10 a day.
- Email when a scheduled alert stops arriving. Direct: No. Via HoldAlarms: Yes, with a heartbeat: "If no beat arrives within the interval plus 60 seconds, we email you once, and again when beats resume".
- Hops. Direct: One. Via HoldAlarms: Two (TradingView → HoldAlarms → endpoint).
When going direct is fine
If your endpoint always answers in well under 3 seconds and is always up, going direct is simpler and costs nothing. There's no extra service in the path.
The trade-off
HoldAlarms adds a hop, so each alert reaches your endpoint slightly later than it would directly. It doesn't cut latency. What you get in exchange is more time for your endpoint to answer, retries, and a dead-letter queue for failed alerts, with failure emails grouped and capped at up to 10 a day. HoldAlarms also can't help with an alert TradingView never sent.
Questions
Does TradingView retry webhooks?
Sometimes. If your server returns HTTP 500–599 (except 504), TradingView sends the webhook again after 5 seconds, with a total of 3 such resends. A request that takes longer than about 3 seconds is cancelled.
Does HoldAlarms reduce latency?
No. It adds a hop. It gives your endpoint more time to answer and retries if it doesn't.
What happens if my endpoint is down for an hour?
Retries finish within about 3 minutes, or up to about 6 with Retry-After. After that the alert is parked in the dead-letter queue; email support and we'll look at it with you.
Do I need to change my endpoint?
You point the TradingView alert at your HoldAlarms URL and add your endpoint as a destination. See the FAQ.
Will I be told if an alert stops arriving?
A heartbeat emails you if a scheduled alert stops arriving. It can't tell you about a single alert that wasn't sent.
Guides
- Why didn't my TradingView alert fire?
- TradingView webhook timeout: why "request took too long" happens
- TradingView webhook not received: 7 things to check
- Duplicate TradingView webhook alerts: why they happen and how to dedupe them
- The TradingView webhook checklist
- Does TradingView retry webhooks?
- TradingView → HoldAlarms → n8n: step-by-step
- TradingView → HoldAlarms → TradersPost: setup and limits
- TradingView → HoldAlarms → PineConnector: setup
- TradingView → HoldAlarms → SignalStack: setup
- TradingView → HoldAlarms → PickMyTrade: setup
- TradingView → HoldAlarms → CrossTrade: setup and limits
- TradingView → HoldAlarms → Alerio: setup
- All HoldAlarms questions
HoldAlarms is not affiliated with TradingView. TradingView is a trademark of TradingView, Inc.