Should alerts fire on bar close or in real time?

Intrabar alerts act sooner but can fire on values that unwind before the close, especially with indicators whose current-bar value keeps moving until confirmation. Bar-close alerts are stable but later. The deciding rule: fire the way your testing evaluated. A closed-bar backtest paired with tick-level alerts is quietly trading a different system.

What should a webhook payload include?

Structured, explicit fields: symbol, action, order type, quantity or risk fraction, price, stop, target, a timestamp, a strategy identifier, and an authentication secret. Explicit beats clever; the receiver should never infer intent from prose. An idempotency key or signal ID also lets the receiver drop duplicates safely.

Are webhook deliveries guaranteed?

No. Platforms rate-limit and expire alerts, endpoints go down, requests time out and may be retried. Production pipelines assume this: log every fire, deduplicate on a signal ID, alert on silence as well as on activity, and periodically reconcile open positions against the orders the system believes it sent.

Why did my alert fire but my backtest shows no trade there?

Usually a timing mismatch: the alert evaluated intrabar values while the backtest evaluated closed bars, or the indicator repaints, so the historical plot no longer shows the condition that fired. Align the firing policy with the backtest's evaluation timing, and prefer repaint-safe conditions for anything automated.

Is it safe to expose a webhook endpoint publicly?

Treat the URL as a secret but never as the only defense. Validate an authentication token in every payload, reject malformed requests, restrict actions to a whitelist, and make execution idempotent. An unvalidated endpoint that translates JSON into orders will execute anyone's JSON, not just yours.

Concept

Alerts & Webhooks

Alerts & Webhooks, also known as alert scaffolding, payload design, are Meta & Composition concepts. A reference entry: the Library explains it rather than implements it.

What are Alerts & Webhooks?

An alert is a platform notification that fires when a chart condition evaluates true: price crosses a level, an indicator flips state, a breakout confirms. A webhook is the delivery mechanism that turns the alert into action: an HTTP request carrying the alert's payload, usually JSON, to another system the moment it fires (a bot, a broker bridge, a journal, a messaging channel). Together they are the seam between analysis and automation.

Two design layers matter. Alert scaffolding is the condition side: signals distilled into booleans that fire once per event and are evaluated on confirmed bars, so the alert cannot fire on a value that un-happens before the close (repaint-safe engineering and signal hygiene live here). Payload design is the message side: structured fields such as symbol, action, quantity or risk, price, stop, an identifier, and a secret, so the receiver can act without parsing prose.

It matters because alerts remove screen-watching and webhooks remove the manual step between signal and order, enforcing the plan exactly as written. The same property is the risk: automation amplifies whatever the signal actually is, so an over-firing or repainting alert becomes real orders. And delivery is not guaranteed (platforms throttle, endpoints fail), so live pipelines need logging, deduplication, and reconciliation.

How to build an alert-to-webhook pipeline

The pipeline is the same whether the receiver is a notification channel or an execution bot; only the stakes differ.

1Reduce the idea to a machine-checkable condition and choose the firing policy: once per bar close is confirmed but later; every tick is faster but can fire on readings that unwind before the bar completes. Match whichever policy your testing actually evaluated.
2Design the payload as explicit fields (symbol, action, order type, quantity or risk, price, stop, target, timestamp, strategy identifier, authentication token) rather than free text the receiver has to interpret.
3Point the alert at the receiver's webhook URL, validate the token server-side, and make handling idempotent: a retried or duplicated delivery must not execute twice.
4Test end-to-end on paper or minimum size, log every fire and every resulting action, and monitor the gap between them; alerts can be throttled, expire, or arrive late, and positions should be reconciled against what actually filled.

How traders use it

As a notification layer: a watchlist of conditions (a support level touched, a volume spike, a screener hit) becomes pings, so attention is spent only when something happens.
As semi-automation: the alert arrives carrying full trade details and a human confirms the order, keeping discretion at the final step while removing the watching and the arithmetic.
As full automation: the webhook feeds an execution bridge that converts the payload into orders, which is where closed-bar firing, idempotency, and authentication stop being optional.
As infrastructure beyond execution: webhooks feed journals, dashboards, and statistics automatically, so every fired signal is logged whether or not it was taken.

Alerts & webhooks vs. related concepts

Signal Hygiene: Hygiene governs the quality of the signal stream itself: deduplication, debouncing, firing once per event. Alerts and webhooks are the transport that delivers whatever the stream contains; a clean pipe does not clean a dirty signal.

Repaint-safe Engineering: Repaint-safety is about whether the condition is stable at fire time; an alert inherits any instability in the logic beneath it. One discipline makes the signal trustworthy, the other moves it somewhere.

Filter-setup-trigger-exit Architecture: Architecture defines when a signal exists by sequencing roles (filter, setup, trigger, exit). Alerts and webhooks define what happens after it exists: notify, log, or execute.

Concept family

Meta & Composition

28 concepts mapped · 28 in the Library

Alerts & Webhooks FAQ

Turn Alerts & Webhooks into a trading strategy.

Describe your Alerts & Webhooks idea to Quant. It builds the strategy with you and backtests it on real data.

Previous conceptAdaptive Parameterization Next conceptAlternative Bar Types