Work through these before raising a ticket — most incidents are one of the first three.
A signal fired but no order was placed
Check, in this order:
- Broker session. Most Indian broker APIs expire their session daily and require re-authentication. An expired session is the single most common cause.
- Risk rules. An order blocked by your own limit looks identical to a failure. Check the logs for a rejection reason before assuming something broke.
- Market hours and instrument. Verify the instrument was tradeable at that moment — closed segment, expired contract, or a symbol that changed after an expiry roll.
- Alert payload. Confirm the alert body matches the expected format. A single mismatched field name will produce a silent rejection.
Orders are placed twice
Usually the alert, not the bridge. Check whether your alert is set to fire "Once Per Bar" rather than "Once Per Bar Close" — an intrabar condition can trigger repeatedly as price moves within the same candle.
The signal fires at a different price than the backtest showed
Expected, and not a defect. Backtests assume fills at the signal price with no slippage or latency. Live orders travel through a network, a broker, and an exchange queue. The gap is real and applies to every automated system.
An indicator shows different values than it did yesterday
If the indicator evaluates on an unclosed candle it can repaint — the historical view is recalculated once the candle closes, so what you see now may not be what fired then. Each product page states whether this applies.
Everything looks fine but nothing runs
Check the service is actually up and that your instance has not been suspended for non-payment. Then check the logs for the session start.
Still stuck
Send us: the timestamp, the instrument, what you expected, what happened, and the relevant log lines. Those five things let us answer in one reply instead of five.
Contact support — and for billing, account or security issues, email [email protected] directly rather than using a chat channel.