Troubleshoot Alerts vs Fills

Alerts vs Fills

Use this page when Alerts vs Fills does not show the comparison you expect. Start with one known signal and broker record, then change one scope or tolerance setting at a time.

No Alpaca fills load

1. In the filter panel, select the Alpaca connection for the account whose orders you want to review.

2. Confirm that its environment is correct—paper and live accounts have different order histories.

3. Select a symbol and date range that contain a known filled order, then choose Load or Reload now.

4. If the product reports an authentication error, reconnect or update the connection in Account Integrations.

An empty result can also be valid: the selected account, symbol, and period may contain no fills. Verify the same filters in Alpaca before treating it as a platform error.

Webhook alerts do not appear

Confirm Webhook events is the TradingView source, then check:

• the same symbol and date range used for fills;
• recent events in the webhook history;
• entry/exit and long/short fields in the captured payload; and
• whether Webhook Data is enabled when Auto-Refresh is active.

See Webhook Integration and the Webhook Payload Standard. To separate capture from matching, compare a known alert-log export using CSV import.

The alert CSV does not parse correctly

Select the timezone used by zone-less timestamps before loading the CSV. The current choices are Browser local time, US Eastern (NYSE), and UTC.

The TradingView alert-log parser expects the exported log shape, including Description and Webhook Status, and maps the JSON payload inside the description. Inspect the imported row count and compare one timestamp, symbol, price, and position direction with the source log.

Because alert-log timestamps may have only minute precision, CSV matching uses an effective time window of at least 60 seconds even when the visible setting is smaller.

Everything is unmatched

The matcher pairs an alert with a broker record only when all of these rules are satisfied:

1. the normalized symbol agrees, when the alert supplies one;
2. the broker position_intent represents the same entry/exit and long/short intent;
3. the broker submission time—or fill time when submission is unavailable—is at or after the signal;
4. the closest candidate falls inside the effective time window; and
5. the absolute price difference is inside the price tolerance.

Each broker record is consumed once after a successful match. Quantity difference is calculated for review but is not currently a match criterion.

Use Scope and Matching for the current defaults and setting behavior.

Many alerts or fills remain unmatched

Investigate one pair instead of adjusting all settings at once:

1. compare symbol and position intent;
2. compare the alert time with broker submission and fill times;
3. compare the alert price with the broker average fill price;
4. look for another alert that may have consumed the closest broker candidate;
5. change only the time tolerance, rerun, and inspect the same pair; then
6. restore it and test price tolerance separately if needed.

Unmatched TradingView alerts and unmatched Alpaca fills are observations. They do not by themselves prove webhook failure, a manual order, duplicate delivery, or a Pine logic defect.

A broker record occurred before the signal

Broker records whose matching timestamp is before the TradingView signal are not eligible. This enforces the review sequence signal → broker order → fill.

If the records should represent the same event, compare the raw source clocks:

• webhook receipt or CSV timestamp and its timezone;
• Alpaca submitted_at; and
• Alpaca filled_at.

Correct the timestamp interpretation or source data. Do not widen the time window: a larger forward window cannot make an earlier broker record causal.

The closest candidate still does not match

Within the expected symbol and position-intent group, the matcher chooses the closest candidate by time and then applies type, time, and price checks. A different broker record may look plausible but will not be selected if a closer candidate occupies that intent group.

Inspect nearby orders for duplicates, retries, or several fills with the same intent. Record the candidate timestamps and prices before concluding the matcher is wrong.

Price difference looks wrong

Confirm the compared fields first: the TradingView alert price and Alpaca average fill price may describe different moments. Also check order type, intended price, side, and market conditions in the source records.

The report shows both raw and direction-adjusted differences. “Favorable” or “unfavorable” depends on whether the event is a long/short entry or exit; it is not determined by the sign alone.

There is no universal acceptable percentage. Choose a tolerance that identifies the intended event pairs, then assess each fill in its order and market context.

Quantity differs but the row matched

This is current behavior. Quantity difference is reported but not included in the match decision. Review it separately when order sizing matters.

For partial exits, TradingView exit legs sharing a trade number are retained as separate events. Each still needs a distinct broker record. Repeated scale-in entries under the same TradingView trade number may not be represented as a complete position lifecycle, so verify those sequences manually.

A match is event alignment, not execution approval

A matched row says the current symbol, intent, time, and price rules accepted the pair. It does not establish profitability, suitable sizing, or correct portfolio state.

Latency looks unexpectedly large

The report separates signal-to-submission, submission-to-fill, and total signal-to-fill timing when those timestamps are available. Inspect the raw pair and confirm the source clock before attributing delay to any component.

A few long observations can move an average substantially. Review the distribution and individual rows; do not infer webhook, broker, or market cause from the aggregate alone.

See Metrics and Analysis.

The chart has no bars or markers

Check:

• the selected symbol, date range, and market session;
• the active Alpaca connection and its configured data feed;
• whether that account’s data entitlement covers the requested instrument and history; and
• whether Market Data is enabled for Auto-Refresh.

The fill/alert comparison and the market-data chart are separate inputs. Missing bars do not erase comparison rows. If rows exist, continue the row review while resolving market-data access.

Auto-Refresh does not turn on

Auto-Refresh requires a selected Alpaca connection. It is also blocked when the connection has a current authentication error.

Available intervals are 5 seconds, 10 seconds, 30 seconds, 1 minute, 5 minutes, and 10 minutes. Choose which inputs refresh:

• Market Data
• Trade History
• Portfolio Snapshot
• Webhook Data

Follow Current Time advances the range end. Without it, Auto-Refresh can reload a fixed range. Background-browser throttling may delay refreshes, so use Reload now before diagnosing an interval failure.

Live Data Feed is unavailable

Live Data Feed requires:

• a Professional or beta account;
• a selected Alpaca connection; and
• a Premium/SIP-capable data feed on that connection.

An IEX-only connection cannot enable this mode. When Live Data Feed is active, Auto-Refresh, Follow Current Time, and Market Data are required and cannot be turned off independently.

Results still show a saved snapshot

Return to the current live view before changing filters. A saved snapshot keeps its stored symbol, dates, source, and tolerances; it does not update with new webhooks or fills. Reload the active data after leaving snapshot mode.

A snapshot cannot be saved

The current comparison must produce a valid report payload, and the account must be below its snapshot cap. Use the in-product status as the source of truth for that cap.

• Narrow the date range if the report is too large.
• Delete an unneeded snapshot if the cap is reached.
• Preserve the active inputs before refreshing after a transient save error.

AI Insights is unavailable or fails

AI Insights requires an eligible plan, configured AI credentials, available credits, and current comparison data. The request contains a bounded sample of comparison and unmatched rows, not the entire dataset.

If generation fails, keep the report open, check the disabled-state or error message, retry once, and continue the row-level investigation if the service is still unavailable. Treat any proposed cause as a hypothesis to verify against the raw alert and Alpaca records.

See AI Insights.

Prepare a useful support report

Include:

• selected Alpaca connection environment, symbol, and date range;
• TradingView source and CSV timezone when applicable;
• time and price tolerances;
• alert, fill, matched, and unmatched counts;
• one expected pair with signal, submission, and fill timestamps; and
• the exact error message and a redacted screenshot.

Never include API keys, webhook secrets, authorization headers, or unredacted account exports.

• Run the quick start
• Configure scope and matching
• Review the visual audit workflow
• Knowledge Base