Order queues: what a queued order is doing and when to cancel

Three different waits use the word queued. One is a wait for the panel to place the order, one is a wait for the supplier's balance to cover it, and one is a wait for an earlier order on the same link to finish. The status word is the same, the owner is different, and the cancellation path is different. The queue note is the part that tells you which one you have.

This guide explains what a queued order is doing, how long each queue can hold it, and when cancelling is the right move. It uses the same event text the order page writes, so you can match the explanation to the line in front of you.

The three queues

The placement queue. After payment the panel creates the order and sends it to the supplier. The order is pending, then placing, until the supplier confirms. The placement timeout is 60 minutes. If the supplier has not confirmed by then, the order is canceled and the wallet is not charged. This queue is the panel's, not the supplier's.

The funds queue. The panel's account with the supplier is short of the order's cost. The customer's money is good, so the panel takes the order, holds the charge and queues it for the next supplier top-up. The status label is Queued. The funds timeout is 180 minutes. If the balance is not topped up by then, the charge returns to the wallet in full.

The same-link queue. A second active order for the same service and link is waiting for the first one to finish. The panel stores the second order as queued and records the first order as its parent. When the parent completes, the second order is released to the supplier automatically. The queue timeout is 180 minutes, and a timeout refunds the second order in full.

Queue	Status you see	Why it exists	Deadline	Money while it waits
Placement	Pending, then placing	The panel is confirming with the supplier	60 minutes	Not charged if it times out
Funds	Queued	The supplier balance is short	180 minutes	Charge held, refunded in full on timeout
Same link	Queued	An earlier order on the link is still open	180 minutes	Charge held, refunded in full on timeout

The deadlines are the defaults in the order engine. The event log on the order page is the source of truth for a specific order.

The symptom that brings people here

What you see: the order says queued, the event log says it is waiting for another order on the same link, or it has been queued for hours with no change.

What it means: read the queue note. If it names another order, you are in the same-link queue. If it says the supplier balance is short, you are in the funds queue. If it says the supplier could not accept it, the panel is retrying a placement that failed.

Next action: open the parent order if there is one, check its state and its remaining time, then decide whether to wait or cancel the queued order before its deadline.

The queue note is not decoration. The order engine writes a different detail for each cause: waiting for the previous order, waiting for supplier funds, the supplier could not accept it, the supplier could not be reached, the service is no longer in the catalogue. Each one points at a different owner and a different remedy.

What a queued order is actually doing

A queued order is not delivering. The count does not move because the order has not reached the supplier's delivery queue. That is the first fact to hold on to: a queued order is a promise to place, not a delivery in progress.

If the queue is the same-link queue, the order is waiting for the parent to finish. The parent can be in progress, partial or completed. The release happens when the parent completes. A partial parent does not release the child in the same way, because the parent has not completed; the child keeps waiting until the parent completes or the child's queue timeout passes.

If the queue is the funds queue, the order is waiting for the panel's supplier balance. The customer cannot fix this by topping up their own wallet, because the wallet is already charged. The panel's owner gets an alert with the shortfall and the deadline. The customer's useful action is to wait for the deadline or cancel while the order is still queued.

If the queue is the placement queue, the order is waiting for a supplier confirmation that has not arrived. The panel is not holding the order on purpose; it is waiting for a network answer. A confirmation that never arrives becomes a cancel without a charge at the placement timeout.

Why the same-link queue exists

Suppliers reject a second active order for the same link and service. The rejection is not a quality judgment; it is a guard against two deliveries landing on the same profile at once. If the panel sent both orders, the second would be rejected, the customer would be charged and refunded, and the net result would be a support ticket with no delivery.

The queue is the panel's way of turning that rejection into a wait. The second order is stored, charged and held. When the first order finishes, the second is sent. The customer gets one delivery after another instead of one rejection and one refund.

The cost is time. A second order placed behind a long parent waits for the parent, not for the supplier's queue. If the parent is a multi-day drip order, the child's 180 minute timeout will pass long before the parent completes. The child refunds and the customer has to place it again. That is the queue working as designed, and it is also the reason a split order on one link is a poor plan.

Worked example

Suppose order A is a hypothetical 10,000 unit Instagram followers order at the median rate. Its charge is $7.35. One hour later, order B is a 5,000 unit order on the same service and link. Its charge is $3.675. Order B is queued behind A.

If A completes ninety minutes after B was created, B is released at that moment. The release is automatic and the event log records it. B then enters the supplier's queue like any other order. The wait for B was ninety minutes of queue plus whatever the supplier takes after release.

If A is still running at the 180 minute mark, B is refunded in full. The event log records the timeout. The customer has the money back and no delivery from B. Placing B again creates a new order with a new clock, and if A is still open, the new order queues behind A again.

The arithmetic is the argument for one order. A single 15,000 unit order at the median rate would have one charge, one queue position and one delivery. Splitting it into 10,000 and 5,000 adds a second charge, a second queue and a second chance to time out. The only reason to split is a link that cannot take the combined quantity, and that is a service limit, not a queue strategy.

When to cancel a queued order

Cancel while the order is queued if the deadline matters. A queued order has not reached the supplier, so the full charge returns to the wallet. The cancel is the cheap exit. Waiting for a parent that may run for hours is only sensible when the parent is close to completion and the delivery is still useful.

Cancel a funds-queued order if the supplier balance is unlikely to be topped up before your deadline. The automatic refund at the funds timeout is the fallback, but the wait is the same 180 minutes. A manual cancel gets the money back sooner and lets you place the order elsewhere.

Do not cancel an in-progress order as if it were queued. Once the supplier accepts, the order is in its delivery queue and the cancellation path changes. The service row has to allow cancellation, and the supplier has to confirm it. If the supplier refuses, the order stays open and no refund is issued. A cancel attempt that fails leaves you in the same state with less time.

The decision rule is simple: cancel before acceptance, ask after acceptance. Before acceptance the panel owns the next step. After acceptance the supplier owns it, and the useful question is what remains, not whether the order can be stopped.

What the queue note tells you

Read the last event, not only the status. A queued order with the note "Waiting for KT... to finish on the same link" is in the same-link queue. A queued order with the note "Still queued: supplier balance is short" is in the funds queue. A queued order with the note "Still queued: the supplier could not accept it" is a placement that failed and is being retried. The notes use the same words the engine writes, so the match is exact.

The event log also records the repeated waiting events at most once per 30 minutes. A long gap between events does not mean the order is dead. It means the panel has nothing new to add. The status change, when it comes, is the event that matters.

If the note names a parent order, open the parent. Its state and its age tell you whether the child will be released soon or will hit its own timeout. That is a two-click check, and it is faster than asking support what the queue is doing.

What the wallet shows while the order is queued

The charge is debited when the order is created, not when the supplier accepts it. A queued order therefore has a wallet entry before it has a delivery. The note on the entry names the service and adds the word queued, which is how you can tell a reservation from a completed charge at a glance.

The money is held against the order, not spent at the supplier. If the order is released and placed, the original debit stands and no second charge appears. If the order times out or is canceled, a refund entry with the order's public id returns the full charge. The net for a canceled queued order is zero.

This is why a queued order is not a loss. It is a reservation with a deadline. The useful check is the pair of entries: the debit with the queued note and, if the order ended, the refund with the same reference. A queued order with a debit and no refund after its deadline is the one case that needs a ticket.

What to do next

If the order is queued behind a parent, check the parent's state and age. If the parent is close to completion, wait. If the parent is a long delivery, cancel the child and place one combined order when the link is free.

If the order is queued for funds, check the deadline in the event log. If the deadline is inside your window, wait for the automatic refund or cancel manually. If the deadline is outside your window, cancel now and place the order with another service.

If the order is queued because the supplier could not accept it, the panel is retrying. The retry can succeed when the service returns. If the service is paused for a long time, the queue timeout is the exit. The customer's action is the same: wait for the deadline or cancel.

If the order is in progress, the queue question is over. Ask for the remains and read the partial guide if the supplier stops short. A cancel at this stage is a supplier decision, not a panel decision.

For the full state sequence, read the order lifecycle. For the refund rules around a queue timeout, read refunds, cancellations and queues. For the money side of a stopped delivery, read partial delivery, and to follow a queued order, open the tracking page.