Signal Logs
Every webhook PineHook has received for your account, with validation, connection tests, trade identities, rejection details, and latency.
Last updated: 2026-10-07
Signal Logs helps you check what happened to each TradingView alert, from its arrival at PineHook through delivery and execution on MT5 or cTrader. Available on every plan, it also lets you validate webhook messages and test a connection before sending live alerts.
Validate or test an alert#
To check a webhook message, paste it in CSV or JSON format into Alert Test & Validate and select Check alert. PineHook runs the message through its webhook parser without placing a trade, then shows the parsed parameters and any warnings or highlights the invalid part with an explanation.
Once the message is valid, Test EA Connection lets you test the live pipeline to an active license without placing a trade or using your alert allowance. For MT5, the results also include broker and account details, EA and terminal versions, and trade-permission flags to review before sending live alerts.
Check delivery and execution#
The live panel shows relay status, received/executed/failed totals, success rate, and average execution time, while individual rows break down where that time was spent. D measures delivery, E measures handling, B records the broker response, and T covers external transport or broker reads when available. The headline total uses D + E, with B and T reported separately.
On cTrader, the execution timestamp stops at the final broker response, or at the confirming broker-state read when no order is needed, so later receipt and ledger writes do not extend it. On MT5, it records when the relay receives the EA's acknowledgment.
Queued alerts#
Alerts awaiting an offline execution connection appear under Queued Alerts. Their eligibility for replay depends on missed-alert recovery settings, so a visible queue does not mean every alert will execute after reconnection.
If you no longer want a queued alert delivered, Clear removes it and records ABDN, abandoned, in the log. Queue entries otherwise expire after 24 hours, independently of the shorter recovery window. To cancel pending delay= alerts instead, use clearqueue.
Rejected signals#
Rejected Signals explains why an alert failed parsing or was refused at execution, with invalid parameters highlighted where available. Errors with matching commands, symbols, and parameters appear together with a count such as ×100, so you can expand a group to inspect its alerts without reading each repeat separately. Use the group's X to dismiss it, or select Dismiss All to clear the panel.
These dismissals carry across browsers and devices, hiding the panel entries while keeping the retained records.
Missing rejection? Check TradingView
PineHook can associate a rejection with your account only if it recognizes your license, so check TradingView's alert log for the error if the message is too malformed to identify it.
Read status badges#
To find an alert in the main table, filter by its status or license. Retired licenses remain in the Deprecated filter group, so you can still review their recorded trading history after regenerating or deleting a key.
| Badge | Meaning |
|---|---|
| EXEC | The requested command was confirmed as executed |
| FAIL | Execution failed, with the reason shown in the row |
| SENT | Sent to the platform, awaiting confirmation |
| RECV | Received by PineHook, not yet forwarded |
| DLYD | A delay= alert is waiting for its scheduled time |
| BLKD | An older status for duplicate alerts. PineHook no longer creates it: an identical alert that arrives again within 12 seconds is dropped and gets no new row |
| RJCT | The parser rejected the alert |
| ABDN | You cleared the alert from the delivery queue |
| BLCK | A server check blocked it, such as authentication, symbol filtering, or active hours |
| UNKNOWN | The execution outcome is uncertain. Check broker history before retrying |
Execution checks such as spread, position limits, market state, and daily drawdown can also produce a Trade rejected pill showing the observed value and configured limit. If a close instead shows Extreme volatility, it executed with unusually large slippage, and the label describes that fill.
For cancel commands, the row shows how many orders matched and how many were cancelled, with 0 / 0 meaning there were no matching pending orders to cancel.
Trade identity#
Hedging checks and target outcomes#
An opposite entry refused by hedging protection normally shows Skipped: Hedging Disabled. Skipped: Hedging Protection Unavailable means PineHook could not verify the state needed for a protected entry. A close/open or cancel/replace command can report a failure after completing its first leg, so expand the row to check partial effects. See hedging entry protection.
For setposition, the target result shows Complete, Partial, Blocked, or Uncertain, alongside the reported target and confirmed volume. Current unknown means the current broker outcome is unproven; a Last confirmed value describes an earlier confirmed snapshot. Compare the result with the original alert, failure reason, and broker history before retrying partial or uncertain work.
Position and group tickets#
Entry rows show the PineHook Ticket and effective magic for that destination. On hedging accounts, you can use ticket= to target the same logical trade across copied destinations, because this ticket identifies the PineHook trade separately from the broker's order, position, or deal IDs.
A setposition ticket can identify a reusable group with several broker positions. Individual positions still have their own broker IDs, and a dashboard action on one position row affects that row.
On netting and exchange accounts, all trades for a symbol are combined into one position, so neither magic= nor ticket= can select a separate trade within it. Manage that combined position by symbol, as explained in Hedging and netting accounts.
Retention and plan limits#
Accepted, rejected, executed, failed, blocked, and cleared alert records are retained for two years, after which personal identifiers and raw payloads are removed. Trading metadata remains for the dispute-resolution period described in the Privacy Policy.
Every plan includes validation, test controls, queued/rejected panels, and the log table, while alert allowances, license capacity, pending-order limits, and access to delay= depend on your plan. You can check those limits in Subscription tiers.
If an alert never appears in the log, follow Alerts Not Received to check its delivery. Once trades are running, Open Positions provides live management, while Analytics shows closed-trade performance.