Why Is My Limit Order Not Filled? A Paper-Trading Diagnostic Guide

A limit order can remain unfilled because the available trading conditions do not satisfy its price and other requirements. A chart touching your price does not, by itself, prove that your particular order should have executed. Check the order’s actual status, relevant quotes, timing, quantity, and session eligibility before replacing it. Investor.gov defines a limit order as an instruction to transact at the limit price or better; its explanation does not promise that every submitted limit order will fill. Investor.gov order definitions.

This guide is a paper-testing diagnostic framework, not an instruction to buy, sell, or change a live order. Trading involves risk. The examples are fictional and are not financial advice.

Start with the instruction you actually submitted

Your intended trade and the submitted instruction are different pieces of evidence. Write down the symbol, side, limit price, quantity, order type, time in force, and account environment. Then retrieve the broker or simulator’s acknowledgement and order identifier. A button click is not a substitute for that record.

This distinction becomes useful when a screen appears unchanged after submission. The request might have been accepted, rejected, delayed, or never delivered. Repeating the click before checking status can create confusion about which instruction is being reviewed. In a paper environment, practice identifying the original request and its resulting state before making another request. Preserve the exact fields rather than summarizing them as “bought at the limit.” The latter phrase assumes an execution that may never have happened. Begin the investigation with what was sent and what the receiving system says happened to it.

A price touch is an observation, not your fill receipt

Imagine a fictional buy limit at 50.00. A chart later displays a trade at 50.00. That observation tells you that the chart recorded a transaction at that price. It does not identify your order, establish when it was eligible, or demonstrate that enough available shares reached it under the platform’s rules.

To investigate, compare the transaction time with your order’s acceptance time and the relevant quote records. Check the chart’s source and session as well. If the observed trade preceded your accepted order, it cannot explain a subsequent fill. If the chart and simulator use different sources, their observations may not line up. If the interface lacks this evidence, write “insufficient detail” instead of assuming a malfunction. The useful next step is a timestamped question to the provider, supported by the order identifier and sanitized records, rather than a conclusion based on the candle alone.

Understand price control and execution uncertainty

A limit instruction controls the acceptable execution price. A market instruction prioritizes execution but does not specify the same price boundary. A stop order changes its behavior when its trigger is reached. These distinctions are described by Investor.gov and should guide which behavior you expect to rehearse.

Do not interpret an unfilled limit as proof that a market order would be a better strategy. Changing the type changes the question: instead of testing whether an acceptable price is available, you are testing a different execution instruction. Write that change into the paper experiment. State the reference price and the result you intend to observe. Keep the original unfilled case in the journal so it remains part of the evidence. Deleting difficult cases and retaining only successful fills makes later analysis less useful, even when the individual trades were only simulated.

Check session eligibility and time in force

Orders can have restrictions involving session, duration, account permissions, and supported combinations of fields. The applicable rules belong to the specific broker, asset, and environment. Read the current documentation rather than assuming the behavior of one platform applies to another.

For an Alpaca paper exercise, its order documentation is a starting point for supported instructions and session behavior. Record the exact session eligibility and time-in-force fields in your test report. If a requested combination is unsupported, the right diagnostic conclusion is a configuration mismatch, not “the market ignored my order.” Likewise, an order that expired according to its instruction should not be counted as a broker outage. Treat the session as part of the experiment’s definition. This avoids comparing regular-session behavior against a chart or submission that belongs to a different trading window.

Separate unfilled, rejected, canceled, and partial states

“Did not fill” describes several distinct outcomes. A rejection means the system did not accept the instruction under its rules. A cancellation means the remaining instruction was withdrawn. An expiration means its allowed duration ended. An accepted but unfilled instruction may still be working. A partial fill means some quantity executed while a remaining quantity needs separate treatment.

Use the platform’s authoritative status fields rather than this guide’s labels when building software. Status names and transitions vary. Keep both the filled quantity and remaining quantity in a paper journal, along with the time of the latest update. A partial fill should not be converted into either a full position or no position for convenience. The diagnostic question is whether your workflow handles the actual state accurately. If the interface shows conflicting quantities, reconcile them before analyzing profit, loss, risk, or what would have happened to a later exit.

Build a concise order evidence packet

Keep account secrets, private keys, and personal identifying information out of any shared report. An order identifier may also be sensitive in context; share it only through the appropriate support channel. The purpose of the evidence packet is to make the discrepancy answerable. A screenshot can supplement it, but a screenshot that omits the timestamp or status cannot establish an execution sequence on its own.

A repeatable paper-testing exercise

Choose a permitted paper environment and one clearly defined scenario. State the intended instruction before submission, capture the accepted fields, and observe the status without immediately changing it. When the test ends, record whether it filled, partly filled, remained open, expired, or was rejected.

Repeat only after identifying what the next test changes. For example, you might change the paper order’s duration while retaining the same review procedure. Avoid comparing two sessions and attributing every difference to the one field you changed; market observations also changed. These exercises validate your understanding of the workflow and your ability to read its states. They do not measure a profitable strategy. Review the paper-trading guide to distinguish a broker simulator from a private paper-track decision, which records reasoning and does not generate an order or fill.

Why simulator behavior needs its own review

A simulator applies a fill model rather than routing your order into the same live market interaction. Alpaca’s paper-trading documentation identifies limitations involving queue position, market impact, and latency-related slippage. Those omissions matter when you use simulated outcomes to reason about an unfilled live instruction.

Document the simulator’s assumptions next to the test results. If the assumptions are not published or cannot be inspected, label them unknown. Do not call a favorable paper fill proof that a live order would have executed. Similarly, an unexpected simulated nonfill can reflect a model rule rather than a real-market event. The comparison should ask which behavior was modeled, which behavior was observed, and which behavior remains unmeasured. Keep that separation visible throughout the article, journal, and any later performance report.

Avoid turning troubleshooting into a revised strategy

An unexpected state can tempt you to move a limit repeatedly until a fill appears. That may make the screen look resolved, but it also changes the instruction and potentially the research question. Preserve each revision as a separate event linked to the original plan.

If you are testing a strategy, define the replacement policy before seeing the outcome. State when an instruction expires, which evidence permits a revision, and how an unfilled opportunity is recorded. Do not manufacture a successful historical trade by assuming you would have changed the order at exactly the right moment. The backtesting guide explains broader evaluation concerns. Here, the priority is a record that distinguishes the planned rule from an improvised response. A troubleshooting note should explain what was learned without rewriting what the original instruction would have achieved.

How this applies to a Tradewink signal review

A signal can contain an entry, stop, target, and rationale without proving that an order was submitted or filled. In a Tradewink private paper-track workflow, save the reasoning and later review how the idea developed. That record remains separate from any brokerage simulator you choose to use.

Public subscriptions are paper-only; separately approved private beta accounts may submit live broker orders. Do not treat access to a research view, a saved signal, or a paper record as authorization for live submission. If you also practice order entry in a broker’s paper environment, keep the broker’s order receipt alongside the signal record and label each clearly. The stop-loss guide provides related context, but a planned stop level still needs its own execution assumptions. A research plan, a submitted instruction, and an actual fill are different evidence stages.

Limitations and when to seek clarification

This workflow can classify many discrepancies without identifying their ultimate cause. A platform may not expose the event detail necessary to reconstruct an order’s treatment. Documentation may describe supported behavior without showing why one specific instruction did not fill.

When the evidence is incomplete, preserve the unresolved case and ask the provider a precise question through its official support route. Supply the environment, timestamp, instruction, and observed status, with sensitive information removed where appropriate. Avoid accusations based only on a chart touch. This guide does not evaluate execution quality across brokers or promise that a particular order type reduces losses. It teaches a review process that keeps uncertainty visible. If the question involves a real account or consequential order change, rely on the broker’s current authoritative records and your own decision process rather than treating an educational article as an instruction.

Frequently Asked Questions

Why did the chart hit my limit price without a fill?

The chart event alone does not establish your order’s eligibility or execution. Compare order acceptance, quotes, session, quantity, and platform rules.

Does a limit order guarantee execution?

No. Its price boundary does not guarantee that the instruction will fill.

Is a partial fill the same as a failed order?

No. Part of the requested quantity executed. Review the remaining instruction and the actual filled quantity separately.

Should I replace an unfilled limit with a market order?

This guide does not recommend an order change. Such a change alters the price and execution assumptions; define and review it independently.

Does a paper-track decision create an order?

No. A private paper-track record preserves signal-review reasoning and is distinct from a broker simulator’s order receipt.