Questions › Guides

TradingView → HoldAlarms → Alerio: setup

Who this is for: you send TradingView alerts to an Alerio webhook route and want each alert logged, and retried with the same Idempotency-Key when Alerio doesn't accept it.

Why put HoldAlarms in between

TradingView cancels a webhook request if the receiving server takes longer than three seconds to process it (TradingView: webhooks). If your server answers with HTTP 500–599 (except 504), TradingView sends the webhook again after 5 seconds, with a total of 3 such resends (TradingView: webhook resubmission).

Alerio asks senders to retry network failures, 429, 502 and 503 with the same Idempotency-Key and the same payload, and to honour Retry-After (Alerio: webhook route setup). HoldAlarms answers TradingView as soon as the alert is queued, designed to reply fast, well before its timeout, then forwards the alert to your Alerio route. Each delivery attempt gets 10 s. Any reply other than 2xx, a timeout or a network error counts as a failure, and HoldAlarms retries up to 5 times, 2 to 60 seconds apart. If the reply asks for a longer wait (Retry-After), we wait up to 60 seconds. Retries finish within about 3 minutes, or up to about 6 with Retry-After. A retried alert reaches Alerio later than the first try, so decide whether that's acceptable for your strategy. A reply of 400, 401, 403, 410, 413, 414 or 415 is a permanent error: it isn't retried. If every try fails, the alert goes to the dead-letter queue, and failure emails are grouped and capped at up to 10 a day. HoldAlarms adds a hop; it doesn't cut latency.

The Idempotency-Key HoldAlarms sends

Every delivery carries an Idempotency-Key header. It is built from the alert's id and the time HoldAlarms received it, so it is the same on the first try and on every retry of that alert, also after HoldAlarms restarts, and the message is forwarded unchanged each time. A new alert gets a new key. If HoldAlarms restarts while a delivery is in flight, that attempt is sent again about a minute later with the same key and message.

Alerio keeps an accepted delivery's receipt for 24 hours. A retry with the same key and payload gets the stored queue acknowledgment back during that time (Alerio: idempotency and retries). Without a key, a repeated request can be processed twice. Still check Alerio's activity record after any failure.

What you need

A TradingView plan with webhook alerts and 2-factor authentication turned on.
An Alerio webhook route (Sources → Webhook) with its Webhook URL and Webhook Key. Alerio recommends one route per sender or alert stream.
A HoldAlarms account. Starter is €19/mo and Ops €49/mo, after a free trial.

Step 1: Point HoldAlarms at Alerio

In Alerio, open your webhook route and copy its Webhook URL (it looks like https://app.alerio.dev/api/webhooks/…). Keep the URL and the key private (Alerio: webhook route setup).
In the HoldAlarms dashboard under Destinations, paste it into Add a destination URL and click Add destination.
Copy Your webhook URL from the dashboard (it looks like https://api.holdalarms.com/hook/<your token>).

Step 2: Point TradingView at HoldAlarms

Create or edit the alert in TradingView.
In Notifications, tick Webhook URL and paste your HoldAlarms webhook URL.
Paste the message exactly as Alerio's docs show it. HoldAlarms forwards it unchanged. Alerio's docs note that TradingView can't send custom headers, so your route's key goes in the message as auth_token.

HoldAlarms forwards your alert message as sent, with the same media type, so auth_token reaches Alerio. A ; charset=… parameter on the Content-Type is dropped, and HoldAlarms adds its own Idempotency-Key, X-HookWatch-Event-Id, X-HookWatch-Event-Hash and X-HookWatch-Attempt headers. HoldAlarms can't add headers you choose, so use auth_token rather than the X-Alerio-Webhook-Token header. Alerio's limits: content up to 32,000 characters, auth_token up to 512, the whole body up to 512,000 bytes.

Step 3: Test it

Check your HoldAlarms URL first with the free Webhook Checker for TradingView.
Fire a test alert, with the Alerio route in a test mode as Alerio's docs describe (Alerio: Quickstart).
Check three places: TradingView's Alerts log (Webhook status), HoldAlarms (a failed alert shows as Failed, in dead-letter queue under Recent alerts; failure emails are grouped and capped at up to 10 a day), and the matching activity record in Alerio.
A successful reply only means Alerio queued the message. Alerio's docs say "HTTP 200 means queued, not completed", so check the result in Alerio's activity record (Alerio: response meaning).

How Alerio's replies are handled

Alerio reply	What it means (Alerio docs)	What HoldAlarms does
200	Accepted and queued, not yet processed	Delivered; check Alerio's activity record
400, 401, 403, 413	Bad message, wrong key, route disabled or without usable authentication, body too large	Permanent error: no retries, straight to the dead-letter queue
404	The URL doesn't match a route	Retried like other errors, then the dead-letter queue (Alerio advises not retrying this). Put the route's current URL in your HoldAlarms destination
409	Key still in progress (with Retry-After), or reused with a different payload	Retried with the same key and message, waiting for Retry-After up to 60 seconds. HoldAlarms' own retries can't cause the "different payload" case: an alert's key and message don't change.
429, 502, 503	Rate limit or processing temporarily unavailable	Retried with the same key and message, honouring Retry-After up to 60 seconds

Common pitfalls

Wrong or missing key. A 401 means the key is missing or wrong: make sure the TradingView message is valid JSON with the matching auth_token. If you rotate the key, update every alert.
Route disabled. A 403 means the route is disabled or has no usable authentication configured. If the route is disabled, enable it in Alerio.
Wrong URL. A 404 means the URL doesn't identify an available Alerio route. Alerio advises not to retry it automatically; HoldAlarms still retries it, because a 404 can be brief for other destinations. Copy the route's current Webhook URL from Alerio and replace the destination in HoldAlarms; new alerts then go to that route.
Duplicates. Identical alerts from the same HoldAlarms account within 20 seconds are forwarded once. To keep real repeats apart, put {{timenow}} in metadata; Alerio records metadata without using it for routing.
Rate limits. Alerio uses a token bucket and sends Retry-After with a 429. A wait longer than 60 seconds is cut to 60, so a long rate-limit pause can end in the dead-letter queue.
IP filters. HoldAlarms has no fixed outbound IP addresses, so it couldn't pass an IP allowlist anywhere.

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

Questions

Does HoldAlarms send the same Idempotency-Key on every retry?

Yes. The key is built from the alert's id and the time HoldAlarms received it, so every retry of one alert carries the same key and the same message, also after a HoldAlarms restart. A new alert gets a new key.

Can I send the key as the X-Alerio-Webhook-Token header?

Not through HoldAlarms. HoldAlarms can't add headers you choose, so put the key in the message as auth_token, as Alerio describes for TradingView.

What happens if Alerio rejects an alert?

Any reply other than 2xx counts as a failure. A permanent error (400, 401, 403, 410, 413, 414 or 415) goes straight to the dead-letter queue, with no retries. Other errors are retried first, up to 5 times, 2 to 60 seconds apart. Either way, failure emails are grouped and capped at up to 10 a day.

Is HoldAlarms an alternative to Alerio?

No. HoldAlarms only checks and retries delivery to Alerio's webhook URL. What Alerio does with the message is set up in Alerio.

More guides

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