What is time in force? GTC, IOC, FOK and GTD explained
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.
Time in force is the instruction attached to an order that tells the venue what to do with any quantity that does not fill the moment the order arrives: keep it resting until cancelled, cancel it immediately, cancel everything unless the whole order fills, or keep it until a stated time.
Every order has one, whether you set it or not — if you leave it out, the venue or your client library applies a default. This page covers what each common value does, how each one interacts with partial fills, where post-only fits, and why the choice matters more in automated trading than it does by hand.
Why this matters now
By hand, time in force rarely comes up. You place a limit order, it rests, you cancel it later if you change your mind. The implicit value is “good till cancelled”, and you are there to do the cancelling.
Automation changes both halves of that. The process that placed the order may crash, restart, or lose its connection, and a resting order does not care. It keeps working on the venue’s side after the code that meant to manage it has gone. Time in force is the only part of an order that decides how long it can outlive your attention. Choosing it is choosing how much state can exist on the exchange that your system does not currently know about.
How it actually works
- The order arrives and matches what it can against resting liquidity at its price or better.
- Time in force decides the remainder. It either rests, is cancelled, or — for fill-or-kill — the whole order is cancelled as if nothing had matched.
- The final status describes the remainder, not the fill. An order that filled 40% and then had its remainder cancelled or expired may be reported as cancelled or expired. The filled 40% is still in your position. See order lifecycle and partial fills.
The common values:
| Value | Remainder after arrival | Partial fill possible? | Can rest on the book? |
|---|---|---|---|
| GTC — good till cancelled | Rests until filled or cancelled | Yes | Yes, indefinitely |
| IOC — immediate or cancel | Cancelled at once | Yes | No |
| FOK — fill or kill | Whole order cancelled unless fully filled | No | No |
| GTD — good till date / day | Rests until a stated time, then expires | Yes | Yes, bounded |
Not every venue supports every value, and some add their own. Which values an endpoint accepts, and which order types they combine with, is a venue behaviour; check the order endpoint documentation rather than assuming.
How “nothing filled” gets reported
An IOC order that finds nothing to match is a normal outcome, but venues report
it differently. Hyperliquid documents it as an error string:
Order could not immediately match against any resting orders. Elsewhere the
same situation can come back as a successful response whose order status shows
zero filled and the remainder cancelled.
The practical consequence: code handling IOC orders must treat “error” and “accepted, zero filled” as possibly the same event, and must read the filled quantity in both cases. An IOC handler that only checks for an error will mis-read a partial fill; one that only checks status will mis-read a zero-fill error as a failure of the request.
Time in force vs post-only
Post-only is often listed alongside time-in-force values, and on some venues it is literally one of them. Semantically it is a different axis:
- Time in force answers “what happens to what did not fill?”
- Post-only answers “is this order allowed to fill on arrival at all?”
A post-only order must rest, so it is effectively a GTC or GTD order with an arrival condition. It is the mirror image of IOC: IOC may only take, post-only may only make. Full detail in what is a post-only order.
Choosing one when automating
IOC for “take what is there, leave nothing behind”. The order either trades now or is gone, so it cannot sit on the book in a state your system has lost track of. For an aggressive entry or an exit that should not linger, this is the cleanest choice. Expect partial fills and size follow-up orders from what actually filled.
FOK when a partial fill is worse than none. If a partial entry would leave a position too small to manage — for example, below the size you can later close under the venue’s minimum order rules — all-or-nothing is simpler than handling the fragment. The cost is more orders that do not fill at all.
GTC for resting entries, with a cleanup discipline. A GTC order is correct for a limit entry you intend to wait for. It is also the value that produces orphans: orders placed by a process that has since restarted with no memory of them. If you use GTC, reconcile open orders on startup and cancel what you cannot account for — see position reconciliation.
GTD as a dead man’s switch. An order that expires on its own at a known time bounds the damage if your system goes quiet. Where a venue supports it, a short-dated order is a resting order that cleans up after itself.
A note on ambiguous failures: if an order call times out, the order’s time in force tells you what could still be happening. An IOC order that timed out has already finished one way or the other. A GTC order that timed out may be resting right now. Either way you still have to reconcile before retrying — see retrying a failed order is not safe — but the GTC case has more possible states.
Where the boundary should sit
- Set time in force explicitly on every order. Defaults differ between venues and between client libraries, and a default you did not choose is a behaviour you did not review.
- Do not let a model choose it freely. If a model drafts orders, the time in force should come from the tool or the strategy’s configuration, not from whatever the model infers. It is a parameter that is easy to omit and whose consequences show up hours later.
- Match the value to how long you can supervise. If nothing will watch the order after it is placed, prefer a value that ends on its own.
FAQ
What does GTC mean on an order?
Good till cancelled: any quantity not filled on arrival rests on the order book until it fills or you cancel it. It is how most people assume a limit order behaves, but check your venue’s default rather than relying on it. In automated systems it is also the value most likely to leave orders resting after the process that placed them has stopped, so it should come with a startup check of open orders.
What is the difference between IOC and FOK?
IOC (immediate or cancel) fills whatever is available straight away and cancels the rest, so partial fills are normal. FOK (fill or kill) fills the entire quantity immediately or cancels the entire order, so you get all or nothing. Neither leaves anything resting on the book.
Can an expired or cancelled order have filled?
Yes. Time in force applies to the remainder, so an order can fill part of its quantity and then have the rest cancelled or expire. The final status describes what happened to the remainder; the filled part is still in your position. Always read the filled quantity rather than inferring it from the status.
Is post-only a time in force?
On some venues it is expressed as one, but it answers a different question. Time in force decides what happens to the unfilled part of an order; post-only decides whether the order may fill on arrival at all. A post-only order must rest on the book, and is refused if it would execute immediately.