You processed an order this morning. Now it is the afternoon, the customer is on the phone, you search processed orders for their name — nothing. Before you panic about lost orders or start blaming a sync failure: the order almost certainly exists and is fine. What you have hit is the processed-orders search indexing delay, and it catches out nearly every Linnworks user eventually.
What is actually happening
When you process an order in Linnworks, two things happen on different clocks. The order itself moves to processed immediately — stock is finalised, the record exists, fulfilment is complete. But the processed-orders search runs against a separate search index, and newly processed orders take roughly 12 to 24 hours to be picked up by it. Until indexing catches up, the order is real but unfindable by search.
This is a common pattern in large systems: keeping a search index perfectly in sync with every write is expensive, so the index is updated in periodic batches instead. The order data and the search index are two different things, briefly out of step. Nothing is wrong; the search is just behind.
The symptoms
You are looking at the indexing delay if:
- An order processed within the last day does not appear in processed-order search, by name, reference, email or anything else.
- The same order is no longer in open orders — because it genuinely was processed.
- Orders from two days ago search absolutely fine.
- By tomorrow, today's missing order shows up as if nothing happened.
It also bites indirectly, and these are the cases that really confuse people: any tool that finds orders via processed-order search inherits the delay. A repeat-order or reorder feature that looks up a customer's last order will not see an order processed two hours ago. A customer lookup built on order history will not include this morning's brand-new customer until the index catches up. If your workflow is "process the counter sale, then immediately reorder from it", the search-based route will come up empty and it is entirely predictable.
What the delay does NOT affect
This matters just as much, because people see the search miss and assume the whole order is in limbo. It is not. The delay affects the search index and nothing else:
- The order itself exists from the second it was processed, with all its lines, customer details and totals intact.
- Stock movements are immediate. Your levels already reflect the sale.
- Despatch and fulfilment are unaffected — processing completed them.
- Direct retrieval still works. Pulling the order up by its ID, or via views that list recent processed orders rather than searching, will find it fine.
In short: the sale is safe, counted and complete. Only "type a name into processed-order search" is behind. If you are hazy on what processing does and does not change, our open vs processed orders explainer walks through the whole lifecycle.
Workarounds that actually help
1. Keep the order reference at the point of sale
Search is only necessary when you do not know which order you want. If today's orders matter to you today, capture the order reference (or your own internal reference) when the order is created — on the confirmation email, the printed slip, wherever. Direct lookup does not wait for the index.
2. Use open orders for same-day questions where possible
If your flow allows an order to sit in open orders until despatch, it stays fully searchable in the open-order views the whole time. This is not a reason to delay processing counter sales — those should be processed at the point of sale — but for despatch orders, most same-day queries can be answered from open orders before processing happens.
3. Set expectations with the team
Honestly the highest-value fix. Once everyone on the counter and in customer service knows "processed orders take up to a day to appear in search — check tomorrow before escalating", the panic tickets stop. Write it on a sticky note if you have to.
4. Use tooling that does not lean on the search index for recency
Tools built for trade workflows can hold their own record of what they submitted, rather than round-tripping through processed-order search. Trade Order POS, for example, keeps drafts and its own order history at the counter, so one-click reorder from an order you took an hour ago just works — no waiting for Linnworks indexing. Its customer lookup is built from three years of processed orders and refreshes continuously as new orders arrive, so the index delay becomes an implementation detail rather than a daily annoyance. The same applies if you take repeat orders by phone — see handling phone orders without re-keying.
Setting expectations
Can you make the delay go away? No — the indexing schedule is Linnworks' infrastructure, not a setting. Plan around the honest numbers: assume up to 24 hours before a processed order is searchable, be pleasantly surprised when it is quicker, and design any same-day workflow so it never depends on searching for an order processed that day. Do that and the delay stops costing you anything at all.
The honest summary
Processed orders missing from search within a day of processing is normal Linnworks behaviour, not data loss. The order, the stock movement and the customer's goods are all fine; only the search index lags, by roughly 12 to 24 hours. Keep references at the point of sale, answer same-day queries from open orders or your POS history, and tell the team so nobody escalates a ghost.
Trade Order POS keeps its own drafts, order history and one-click reorder at the counter, so you are never stuck waiting for the Linnworks search index to catch up. Try it free for 14 days at trade-pos.mcp-g.com.