Skip to main content

Diagnosing Failed Signals with an AI Trading Agent

When a webhook fails, the answer is usually in your Alert History. The problem is, you have to know what to look for: which row, which error code, which payload field, which add-on log entry from the same minute. An AI trading agent connected through MCP can do the lookup and the explanation in one pass.

This article walks through what to ask, what the agent should call, and what a useful answer looks like in three real scenarios: a bad key, a disconnected account, and a position sync mismatch.

Related references: Talking to Your Add-On with AI, Alert History, MCP Trading API, and Operations and Safety Prompts.

The pattern​

Most signal-failure conversations follow the same shape:

  1. You notice something is off (an order didn't fill, a position is the wrong size, the dashboard shows a red row).
  2. You ask the agent to inspect the most recent failures.
  3. The agent calls GetSignalHistory with a status filter, gets back rows that already include a structured help block when the error matches a known pattern, and explains each failure in context.
  4. If needed, the agent cross-references GetActivityLog to see what the XT Add-On was doing at the same moment.

You stay in the chat. The agent does the dashboard navigation for you.

Open with a broad failure pass​

Start with the lowest-effort prompt that still scopes the investigation.

Why did my last 10 signals fail? Use GetSignalHistory with status="failed" and a limit of 10. For each failure, read the help block (title, explanation, common_causes, how_to_fix) and explain it to me in plain English. Group failures by error code so I can see the pattern.

What the agent should do: call GetSignalHistory(status='failed', limit=10, include_help=true), group the rows by error, and present a short summary per group. This gets you out of "scrolling Alert History looking for red rows" and into "here are your three failure modes, in order of frequency."

If you want a bigger window or you suspect a specific instrument:

Show me every failed signal for MNQ in the last 24 hours. Use GetSignalHistory with status="failed", a search of "MNQ", and a limit of 100. Summarize by error code, then show me the worst three rows in detail with payload, error, and help block.

Scenario 1: invalid_secret_key​

A common failure for users who rotated their key, or pasted the wrong one into a new alert. The signal hits the webhook but never makes it past authentication.

One of my alerts is failing every time. Pull the most recent failed signal and tell me what happened.

What the agent will see: a row with error: "invalid_secret_key", a help block with title: "Secret key is missing, invalid, or inactive", common causes including "key= line missing or has a typo" and "key was regenerated and the alert wasn't updated," and how-to-fix steps pointing to the dashboard's My Account page.

A good agent response sounds like:

Your most recent failed signal at 14:08:12 failed with invalid_secret_key. CrossTrade rejected the alert because the key= value in the payload didn't match any active key on your account.

Most common causes:

  • The key= line is missing entirely from the alert message.
  • There's a typo (a leading or trailing space, or you pasted the webhook URL fragment as the key).
  • You regenerated the key recently and the TradingView alert still has the old value.

Fix: copy your current secret key from app.crosstrade.io/user/my-account, open the alert in TradingView, and replace the key= value. Save the alert.

Want me to confirm this is the only key problem in the last day, or pull other failures too?

That's the help block, rendered as conversation. No hunting through the dashboard.

Scenario 2: account_not_connected​

Less obvious. The key is fine, the payload is fine, but the target account isn't currently reachable from the add-on.

An APEX alert failed about 20 minutes ago. Find it in Signal History, then check the add-on Activity Log for the same window so we can see whether the connection dropped.

The agent will call GetSignalHistory(search='APEX', status='failed', limit=20) and then GetActivityLog(lookback_hours=1, levels=['Info','Warning']). The signal row will carry error: "account_not_connected" with a help block explaining that the account name doesn't appear in NinjaTrader's currently-connected master list. The Activity Log will usually show a corresponding connection-dropped Warning or a feed reconnect event nearby.

A good agent response sounds like:

Found the failure. At 13:48:09 your alert for APEX-282538-07 came in, and CrossTrade rejected it with account_not_connected. The help block explains: "The specific NinjaTrader account is not currently connected, even though the XT Add-On may be running."

Cross-referencing the Activity Log: at 13:47:51, the add-on logged a Warning that the Rithmic data feed disconnected. At 13:48:42, the feed reconnected. So the alert landed in a 51-second window where the data feed (and therefore the account) was offline.

This is a feed-stability issue, not an alert issue. Recommended steps:

  • If this is happening more than once a day, consider running NT8 on a VPS for a stable network environment.
  • Buy your own data subscription (Rithmic, CQG, Kinetick) and connect that feed first, then layer prop accounts on top.

Want me to count account_not_connected failures across the last 7 days to see if this is a pattern?

The cross-reference with GetActivityLog is what turns "this signal failed" into "this signal failed because the data feed dropped for 51 seconds."

Scenario 3: position_out_of_sync​

The most situational of the three. The account is connected, the key is fine, but the position quantity in NT8 doesn't match what the signal expected.

I see a "sync" warning on a recent alert. Find it with GetSignalHistory, explain what happened, and tell me whether my position is currently in the expected state.

The agent should call GetSignalHistory(search='sync', limit=20) (the search field looks at id, multiacct, request, and error strings). The matching row will carry warning: "position_out_of_sync" and a help block: title "Position Out of Sync," explanation that the monitored position doesn't match the most recent strategy state, common causes including manual trades inside NinjaTrader and missed alerts, and a fix list that includes using out_of_sync=resync to auto-correct on the next signal.

A good agent response sounds like:

At 10:14:33, your strategy sent an exit signal for MES expecting a long 2-contract position, but NT8 reported a long 1-contract position. CrossTrade flagged the row with position_out_of_sync and let the trade proceed against the actual quantity rather than blocking it.

Most common causes:

  • A manual trade or exit was placed directly in NinjaTrader between strategy signals.
  • A previous entry signal was missed (lost connection, TV throttle, or wasn't fired).
  • The strategy is sending duplicate signals from two places (TradingView and the dashboard, or two strategies on the same account).

Fixes:

  • Review your XT Add-On Activity Log around the previous entry timestamp to see whether one of the entries failed silently.
  • If you intend to allow manual exits, add strategy_exit_block to the alert.
  • For automatic recovery on the next signal, use out_of_sync=resync to let CrossTrade align position size to the new target.

Do you want me to pull the corresponding XT Add-On Activity Log entries for that window, or count recent sync warnings to see if this is a one-off?

Sync warnings are not always failures. The help block makes that distinction explicit, which keeps the agent from over-reacting.

When the agent should stop and ask​

If the agent is about to fix something for you (regenerate a key, change account settings, modify a strategy), make it confirm first.

Investigate the last 20 failed signals on my account. Do not place any orders, regenerate any keys, or modify any settings. Just diagnose, and at the end tell me which fixes I should consider in priority order.

Read-only by default. Mutations come after explicit user confirmation. This is the same safety frame from the account and risk prompts for trading-side actions, applied to diagnostics.

When the AI says "I don't have data"​

Two cases:

  • The add-on is offline. GetActivityLog will come back empty. The agent should say so explicitly ("the XT Add-On appears to be disconnected, so I can't pull recent activity log entries") and recommend reconnecting NT8 before going further.
  • The error doesn't match a known pattern. Not every failure has a curated help block. When the help_key is missing, the agent should fall back to the raw error string and the raw payload, and tell you so: "this signal failed with error unknown_handler_response and there's no help block registered for that. The raw payload was <…>. I'd recommend forwarding the Order ID to support."

Honesty about the data the tool returned is more useful than a confident hallucination.

What this replaces​

Without an agent: open Alert History, filter by failed, click the row, read the error, click into the Help modal if available, switch windows to NT8, open the Activity Log, scroll to the right timestamp, correlate by eye.

With an agent: "what failed and why?" → answer.

Both surfaces still exist. The Alert History page and the Activity Log are still the canonical places to browse data. The agent is the fastest way to get a question answered.

Next: see Operations and Safety Prompts for the broader catalog of agent prompts beyond diagnostics, or the reference page on Talking to Your Add-On with AI for the underlying tool details.