DEV Community: HookWatch

Connecting an AI trading agent to TradingView alerts without losing signals

HookWatch — Mon, 12 Oct 2026 23:32:40 +0000

Disclosure: I work on HookWatch, a hosted TradingView webhook reliability layer. Everything below works without it, and the code is MIT on GitHub.

A lot of people are wiring LLM agents to TradingView right now: an alert fires, the agent looks at the signal plus context (position, news, PnL), decides, and places an order. The first version usually looks like this:

@app.post("/webhook")
async def webhook(req: Request):
    signal = await req.json()
    decision = await agent.decide(signal)   # 3-15 seconds
    if decision.execute:
        broker.place_order(...)
    return {"ok": True}

It works in testing, then you start losing signals in production. Here's why, and the boring pattern that fixes it.

TradingView gives you about 3 seconds

From TradingView's own docs: if the receiving server takes longer than about 3 seconds, the request is cancelled. Also: ports 80/443 only, no IPv6, no custom headers, and the body is text/plain unless your alert message is valid JSON.

An LLM call alone usually takes longer than 3 seconds. So the handler above times out, TradingView treats the delivery as failed, and depending on where the code was when the connection dropped, your agent may or may not have acted. You get no retry you can rely on and no log on your side.

Split the handler from the agent

The webhook handler should do four cheap things and return:

Verify a secret carried in the JSON body (TradingView can't send auth headers).
De-duplicate on an alert_id you build in the alert message, e.g. {{ticker}}-{{interval}}-{{timenow}}.
Timestamp and enqueue the signal.
Return 200 within milliseconds.

The agent runs in a separate consumer:

@app.post("/webhook")
async def webhook(request: Request):
    signal = json.loads(await request.body())
    if not hmac.compare_digest(str(signal.pop("secret", "")), SECRET):
        return Response("forbidden", status_code=403)
    alert_id = signal.get("alert_id")
    if not alert_id or alert_id in seen:
        return Response("ok", status_code=200)   # duplicates get 200 too
    seen[alert_id] = time.time()
    signal["_received_at"] = time.time()
    try:
        signals.put_nowait(signal)
    except asyncio.QueueFull:
        return Response("busy", status_code=503)
    return Response("queued", status_code=200)


async def consumer():
    while True:
        signal = await signals.get()
        decision = await agent_decide(signal)       # slow is fine here
        if risk_gate(signal, decision):
            place_order(signal, decision)

Full runnable versions (FastAPI, Express, and the agent one): github.com/hookwatch-ops/tradingview-webhook-examples

Put a deterministic risk gate after the agent

The agent proposes; plain code decides whether anything reaches the broker. At minimum:

Max signal age. If the queue backed up and a signal is 2 minutes old, a market order on it is probably wrong. Drop it.
Position and size limits the model can't talk its way around.
Structured output only. Parse the agent's answer into a fixed schema; anything else is a skip.

The part a fast handler doesn't fix: downtime

Fast ACK solves the 3-second problem. It doesn't help if your process is restarting, your VPS reboots, or you're deploying a new agent prompt at the moment the alert fires. TradingView doesn't queue alerts for you.

The fix is to make ingress separate from the bot:

a tiny always-on receiver (or serverless function) that only writes to a durable queue: Redis Streams, SQS, Postgres
durable dedupe: Redis SET alert_id 1 NX EX 86400 or a unique index
retries with backoff from the queue to the agent, and a dead-letter queue for signals that keep failing, so you can see what was missed
an alert to yourself when no signals arrive during hours you expect them

Then your agent can crash, restart and redeploy without signals vanishing.

If you don't want to run that part

That ingress layer is what HookWatch does as a service: you point the TradingView alert at your HookWatch URL, it answers TradingView right away, queues the alert, delivers it to your receiver, retries failed deliveries (5 automatic retries over about 2 minutes) and keeps anything that still fails in a dead-letter queue. It's not signals and not a broker, and it doesn't make alerts faster; it just stops them from disappearing silently. There's a free trial (300 alerts or 7 days, no card) if you want to try it in front of your agent.

Either way, keep the secret check and the idempotency in your own receiver.

Checklist

[ ] Handler returns 200 in well under 3 s, never calls the LLM
[ ] Secret in the JSON body, constant-time compare
[ ] alert_id in every alert message, de-duplicated durably
[ ] Agent runs from a queue, with a max-signal-age check
[ ] Deterministic risk gate between agent and broker
[ ] Ingress survives bot restarts (your own queue or a hosted layer)
[ ] You look at failures (DLQ / logs), not just successes

Not financial advice. Paper-trade any agent before giving it real money.

TradingView webhooks and the 3-second timeout: ACK fast, deliver later

HookWatch — Mon, 12 Oct 2026 15:09:01 +0000

TradingView sends alert webhooks as HTTP POST requests to a URL you choose, with the alert message as the body. Its docs are short and strict: "If a remote server takes longer than three seconds to process a request, the request will be cancelled" (How to configure webhook alerts).

TradingView resends in one case only: when your server answers with a status between 500 and 599, except 504. It waits 5 seconds and resends, up to 3 times, so at most 4 sends per trigger (Webhook resubmission). It doesn't resend timeouts.

A few other limits from the same docs are worth knowing before you debug anything else:

Only ports 80 and 443 are accepted.
IPv6 isn't supported, so your hostname needs an IPv4 (A) record.
Webhook alerts only work with two-factor authentication enabled on the TradingView account.
The request is sent as application/json if the message is valid JSON, otherwise as text/plain.

What goes wrong in practice

If your endpoint does real work inside the request (calling a broker API, writing to a sheet, posting to Discord), you're racing that clock. People often report the same pattern: the alert log flags the webhook as failed, yet the destination got the data. The work happened, but the 200 came back too late. The Webhook status column in TradingView's alert log is where to look.

Restarts are subtler. If a reverse proxy answers 502 or 503 while your app restarts, TradingView will resend (three times, 5 s apart), and you may get the alert once the app is back. But if the connection is refused, the request times out, or the proxy answers 504, there's no resend and that alert is gone.

The pattern that fixes it

Receive the POST and check a shared secret. TradingView's alert setup gives you a URL and a message, so put the secret in the message body (or in an unguessable URL path), not in a custom header.
Write the payload to a durable queue and return 200 immediately.
Have a worker deliver it to your bot, with its own retries and backoff.
Make handling idempotent, because the same alert can arrive more than once.
Park messages that keep failing in a dead-letter queue (DLQ), so you can inspect them instead of losing them.
Reconcile TradingView's alert log against your order log daily, and keep protective stops resting at the broker.

Python (Flask sketch)

import json
from flask import Flask, request

app = Flask(__name__)
SECRET = "your-shared-secret"

def enqueue(raw: bytes) -> None:
    """Persist the raw alert (Redis list, SQLite/Postgres table...). Must be fast and durable."""
    ...

@app.post("/webhook")
def webhook():
    raw = request.get_data()
    try:
        if json.loads(raw).get("secret") != SECRET:
            return ("", 401)
    except ValueError:
        return ("", 400)
    enqueue(raw)          # persist first
    return ("OK", 200)    # ACK before any broker / Redis / Discord work

Node (Express sketch)

app.post("/webhook", express.raw({ type: "*/*" }), async (req, res) => {
  let msg;
  try { msg = JSON.parse(req.body.toString("utf8")); } catch { return res.sendStatus(400); }
  if (msg.secret !== process.env.SECRET) return res.sendStatus(401);
  await enqueue(req.body);      // persist first (your durable queue)
  res.status(200).send("OK");   // ACK before slow work
});

With a message like:

{"secret": "your-shared-secret", "id": "{{ticker}}-{{interval}}-{{time}}-{{strategy.order.action}}", "action": "{{strategy.order.action}}", "ticker": "{{ticker}}"}

The id gives you idempotency. Use the bar time {{time}}, not {{timenow}}, so the id is tied to the bar that fired and stays the same across resends. Two caveats: {{strategy.order.action}} only exists in strategy alerts, and messages built with Pine's alert() function don't substitute placeholders at all (Pine FAQ: alerts). For those, build the same string in Pine with str.format() from syminfo.ticker, timeframe.period and time.

What we built

We build HookWatch, which runs this ACK, queue, retry and DLQ layer as a hosted service for TradingView webhooks. Each alert is queued and answered with a 200 well inside TradingView's window. If your bot doesn't accept it, we retry delivery 5 times (after 2, 5, 15, 30 and 60 seconds, about 2 minutes in total). Alerts that still fail are parked in a dead-letter queue instead of being lost, and support can resend them. There's also an optional heartbeat that emails you if TradingView stops sending. It isn't a signal service and isn't a broker, just delivery. Keep your bridge; we handle the delivery hop to it. You still want the idempotency key above, because any retry layer, ours included, can deliver an alert more than once.

Starter is €19/month or €190/year (up to 3 destinations); Ops is €49/month or €490/year (up to 15). There's a free trial: 300 alerts or 7 days, whichever comes first, no card.

If you've built your own receiver for TradingView alerts, we'd like to hear how you handle retries and duplicates, and what you'd need to see before trusting a hosted hop in front of your bot.

https://gethookwatch.com

Disclosure: We build HookWatch, the service described above. This post was drafted with AI assistance and reviewed and edited by the HookWatch team.