A useful trading log report connects the TradingView alert, the PickMyTrade processing record and the broker’s order history. If you’re searching for “pickmytrade logs download,” start with the event you need to investigate. Export the relevant records, preserve their original timestamps and match the account, instrument and order references before drawing conclusions.
Table of Contents
- Key takeaways
- Before you begin: identify the event and account
- Step 1: Export the TradingView alert log
- Step 2: Complete your PickMyTrade logs download
- Step 3: Collect Tradovate order and execution records
- Step 4: Align timestamps without losing the originals
- Step 5: Match the event using more than its timestamp
- Step 6: Write a timeline that separates facts from unknowns
- What should your support report include?
- Common mistakes that make logs harder to interpret
- Comparing PnL totals with alert counts
- Treating notifications as fill confirmations
- Sending screenshots without enough context
- Frequently asked questions
- Finish with an evidence trail you can follow
A chart screenshot may show where you expected an entry. It usually cannot establish when a webhook arrived, whether an order was rejected or how much of an order filled. This guide follows the Tradovate workflow on pickmytrade.trade and explains how to collect evidence that answers those questions.
Key takeaways
- Collect TradingView, PickMyTrade and Tradovate records for the same event.
- Label timestamps with their time zone and event type.
- Preserve the triggered alert message, exact errors and broker order IDs.
- Check entry fills, exits and remaining working orders separately.
- Keep original exports private and share redacted copies through official support.
Before you begin: identify the event and account
Choose one specific incident before downloading a large history. Record the date, approximate time, intended action and account environment.
“The entry did not appear” is a starting point. “The buy alert triggered, but I cannot find a matching Tradovate order in the selected account” gives the investigation a clearer question.
Gather access to the TradingView account that owns the alert, the relevant PickMyTrade login and the destination Tradovate account. Confirm whether the incident involved Demo or Live. If several accounts received the signal, list them separately. One account’s successful fill does not establish what happened in every follower account.
Preserve the records before changing configuration. Note the alert name, strategy or indicator, chart symbol, timeframe and destination contract. If you later correct a setting, record what changed and when. A screenshot of the corrected configuration cannot establish the settings used by an earlier event.
Step 1: Export the TradingView alert log
Export the alert history associated with the event rather than relying only on a chart marker. TradingView’s Manage alerts guide confirms that the alert log can be exported as CSV.
To collect the relevant records:
- Open TradingView’s Alerts panel and locate the relevant log entries.
- Find the alert name and event time surrounding the incident.
- Use the log’s CSV export option and save the original file.
- Preserve the actual triggered message where available.
- Record the alert condition, webhook configuration and active state if relevant.
Remove authentication secrets from the copy you share.
An alert log entry establishes that TradingView recorded a trigger. It does not, by itself, establish successful delivery to PickMyTrade or a broker fill.
Likewise, an empty filtered view needs investigation. Confirm the account, date range, alert selection and available history before concluding that no trigger occurred.
For strategy automation, separate historical backtest markers from real-time alert events. Preserve the event record that relates to the webhook investigation. If the issue concerns unexpected message content, the alert editor alone may not show the values sent when the alert triggered.
Step 2: Complete your PickMyTrade logs download
On pickmytrade.trade, open Alerts Log, select the relevant date range and use Export. The PickMyTrade layout guide documents date filtering and Export, Filter and Columns controls.
Check the downloaded file’s contents. The guide does not define every export format, field or size limit.
Start with a focused interval around the incident. Widen it if related entries, exits or retries fall outside the selection. Check the visible account and environment, then inspect active filters before exporting.
After downloading, confirm that the output includes the event you intended to collect.
Keep the request’s exact status and error text. Capture any available reference linking it to a broker order. If useful details appear only in an expanded entry, preserve a redacted screenshot or text note alongside the export.
Do not describe an application status as “filled” unless the record supports that conclusion.
PickMyTrade’s monitoring guide distinguishes received-alert status from trade history and recommends comparing TradingView records with PickMyTrade records. If the alert appears only in TradingView, retain the CSV and provide it through official support with your registered account details.
If Export is not visible, note the application domain, layout and log page you are using. Describe the missing control to support. Instructions for pickmytrade.io may not have identical controls or fields on pickmytrade.trade.
Step 3: Collect Tradovate order and execution records
Find the broker order IDs and outcomes for the same account and interval. PickMyTrade’s Tradovate order-ID guide documents Account Reports, the Orders tab, date selection, optional filters and CSV or PDF downloads.
Follow these steps:
- Open Tradovate and confirm the intended account and environment.
- Open Account Reports and select Orders.
- Choose the relevant period.
- Apply account, contract or status filters as needed.
- Run the report and use the available CSV or PDF download option.
- Preserve order IDs, status, quantity, contract, execution time and price where supplied.
Include related exits and protective orders when investigating position management.
An entry and its stop are different orders. A filled entry does not establish that the stop was accepted. A flat position also does not establish that every associated working order was canceled.
If the report summarizes executions, obtain the additional detail needed for a partial-fill question. Record requested quantity, filled quantity and remaining quantity separately.
Keep broker labels unchanged so support can distinguish submission, acceptance and execution states.
Step 4: Align timestamps without losing the originals
Convert timestamps into a common time zone while retaining the original values.
TradingView states that alert times displayed in its log use the operating system’s time zone, while exported CSV timestamps use UTC. Changing the chart time zone does not change that CSV behavior. See its alert timestamp documentation.
Create additional comparison columns rather than overwriting source timestamps.
For example, 18:00 IST corresponds to 12:30 UTC on the same date. If a timestamp uses an exchange or regional zone, verify the offset for the incident’s date. Daylight-saving changes affect some locations. Include the date when an event crosses midnight.
Event type matters as much as time zone. A candle’s opening time, alert trigger time, application receipt time, broker submission time and fill time describe different stages.
Subtracting a candle timestamp from a fill timestamp does not isolate webhook delivery time.
| Record | What its timestamp can establish | What it does not establish alone |
|---|---|---|
| TradingView trigger | When TradingView recorded the alert | Successful webhook delivery or broker execution |
| PickMyTrade receipt | When the application recorded receipt | Exact broker submission time |
| Broker submission or acceptance | The stage explicitly identified by that record | A completed fill |
| Broker execution | Recorded fill time, price and quantity | The cause of every earlier delay |
Only calculate a stage’s duration when both endpoints are available and comparable.
If the export lacks a submission timestamp, mark submission time as unknown. A gap between receipt and fill is useful evidence, but it cannot alone identify a queue, reconnect, broker delay or market-related wait.
Step 5: Match the event using more than its timestamp
Use the account, environment, symbol, side, quantity and available identifiers together.
Closely spaced alerts can have nearly identical times. A shared chart symbol also does not guarantee the same executable futures contract. Keep the TradingView symbol and destination contract in separate fields when comparing records.
Build one row per destination account if the signal was routed to several accounts. Include the application reference and broker order ID where available.
For a manual copier incident, identify the source account and affected follower accounts. Collect the actual order records for each. Avoid describing all followers as missing based on one account view.
Treat retries and duplicate-looking records as questions to resolve. They may represent separate requests, child orders, replacements or executions. Match their identifiers and outcomes before calling them duplicate fills.
Do not add unrecognized tracking fields to a production webhook merely to create a reference. Use documented fields and existing IDs.
For configuration questions, use the PickMyTrade documentation hub to locate current instructions. Keep configuration evidence separate from records showing what happened.
Step 6: Write a timeline that separates facts from unknowns
Write the confirmed sequence first, then list what the available records cannot answer.
“No broker order found in this report” is more precise than “the broker never received it,” particularly when the report’s account, filters or time coverage still need verification.
Consider this hypothetical example:
- A TradingView buy alert appears at 12:30:00 UTC.
- PickMyTrade records receipt at 12:30:01 UTC.
- The matching broker order fills at 12:30:05 UTC.
- A related protective order shows rejected.
These invented timestamps illustrate the method. They are not a performance benchmark or customer case.
The evidence describes a filled entry and a protection problem. It does not describe a missing entry webhook.
If submission time is unavailable, the four-second receipt-to-fill interval cannot be divided into application processing, transmission and broker execution from those timestamps alone.
For a delayed-order investigation, ask support to confirm the missing stages:
- When did processing begin?
- Was submission attempted more than once?
- When was the order submitted?
- When did the broker respond?
- Were connection events recorded during that interval?
Ask about queues, retries or connection events as possibilities to check rather than presenting them as established causes.
What should your support report include?
Send a short incident summary with a focused set of records through the official private support route linked from PickMyTrade. Keep the same case reference for follow-up.
Use this template:
Incident date and time zone:
PickMyTrade registered email — private support only:
Broker account and environment:
Alert name, chart symbol and destination contract:
Expected action and quantity:
Observed result and exact error:
Application reference and broker order IDs:
Related entry, exit and protective-order status:
Attached records and their time zones:
Configuration changes after the event:
Question the available records cannot answer:
Remove passwords, tokens, API keys, reset links and full payment information from sharing copies.
Webhook messages can contain authentication secrets, so inspect CSV cells as well as screenshots. Preserve unmodified originals privately and use consistent account aliases in public examples. Provide exact account and order references privately where needed for investigation.
Before replaying an uncertain request, check the broker’s current orders and positions. A timeout or missing application response does not establish that no order exists. Resolve that uncertainty before another entry changes the account state.
Common mistakes that make logs harder to interpret
Comparing PnL totals with alert counts
Alerts, orders, fills and completed trades are different units.
Reconcile the account, period, open versus closed positions, contract quantities and fee treatment before comparing financial results. A performance summary provides context, but it cannot replace the execution records needed to explain an individual trade.
Treating notifications as fill confirmations
TradingView’s alert setup guide lists app, email, sound and webhook actions.
A notification about an alert is not a broker fill confirmation. If a sound or email is missing, inspect the underlying event and order history before assuming the trade did not occur.
Sending screenshots without enough context
Cropped timestamps, unlabeled time zones and screenshots of the wrong account make comparisons difficult. Exports that exclude a related exit can also leave the sequence incomplete.
Keep readable column names, complete error text and enough surrounding history to explain the event. Mark genuinely missing information as unknown instead of filling the gap with an assumption.
Frequently asked questions
Open Alerts Log on pickmytrade.trade and use the documented date filtering and Export controls. Confirm the relevant account, environment and period, then inspect the output for the incident. Keep additional details that appear only in expanded records alongside the export.
It helps establish the recorded alert event, but does not establish broker execution. Compare it with PickMyTrade’s processing entry and Tradovate’s order records. If the event is absent from PickMyTrade after checking the view and filters, provide the TradingView export to official support.
TradingView documents on-screen alert-log times in the operating system’s time zone and CSV timestamps in UTC. Preserve both labels and convert a copy for comparison. The chart’s selected time zone does not determine the time zone used in every alert record.
Only if it contains sufficient evidence. Receipt and fill times show an interval between different stages. Submission attempts, responses and connection events may be needed to explain it. Ask support for missing timestamps rather than assigning the entire interval to one service.
Start with the affected event and enough surrounding records to connect its entry, exits and order changes. Support may request a wider period. Remove secrets and unrelated information from sharing copies while retaining the originals privately.
Finish with an evidence trail you can follow
A useful log collection identifies the account, preserves the triggered message, matches broker orders and explains the time zones. It also states what remains unknown.
Download the relevant records, assemble the timeline and send one focused support report so the investigation starts from evidence rather than a chart impression.
Disclaimer:
This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use.
Also Checkout: Automate TradingView Indicators with Tradovate Using PickMyTrade
