Instagram media container stuck in QUEUE: diagnosis and the delivery-evidence argument

When you call POST /{ig-user-id}/media, Instagram does not publish immediately. It creates a container object and processes the underlying asset — fetching it if you supplied a URL, transcoding video, and validating it against the target format's requirements — asynchronously. You check on that work with GET /{ig-container-id}?fields=status_code, and per Meta's content-publishing documentation, the value you get back moves through a documented set of states: IN_PROGRESS ("the container is still in the publishing process"), FINISHED ("the container and its media object are ready to be published"), PUBLISHED (the media object has actually been published), ERROR (processing failed outright), and EXPIRED — Meta's own words: "the container was not published within 24 hours and has expired."

"Stuck in queue" almost always means a container sitting in the in-progress state for far longer than you expected — not a distinct, documented status of its own. That distinction matters, because it means the fix is about how long to wait and what to do next, not about decoding a special error.

Processing time is not fixed. It scales with the asset — a short image container typically finishes in seconds, while a longer or higher-resolution video (especially Reels) can reasonably take longer, particularly under platform-wide load. A container that is still in-progress a few minutes after creation is not necessarily broken.

Meta's own guidance sets a much shorter expectation than the 24-hour hard limit suggests: its content-publishing documentation recommends "querying a container's status once per minute, for no more than 5 minutes." In practice, developers commonly report containers — especially longer Reels or anything hitting the platform under heavy load — taking longer than that documented window without actually being stuck, so treat 5 minutes as a signal to get more attentive, not as a hard cutoff to abandon the container at.

A few signals are worth watching instead of a single fixed timeout:

• Trajectory, not a snapshot. Poll on the cadence Meta recommends — about once a minute, not tighter — and if the status has not moved after a stretch well past what comparable assets of the same size and format normally take, treat it as suspect rather than assuming it will resolve on its own.
• The 24-hour expiry is the hard backstop. Instagram expires an unpublished container after roughly a day. If you are anywhere near that window, stop waiting and start over rather than risking a publish attempt against an expired container.
• Compare against other containers from the same batch. If ten containers from the same upload batch all finished in under a minute and one has been in-progress for much longer, that one container is the anomaly, not a platform-wide slowdown.

Start with Meta's recommended cadence — about once a minute — rather than tight-looping the status endpoint; hammering it does not speed anything up and risks contributing to rate limiting on an account that is already having a bad day. Past the ~5-minute window Meta's own docs describe as typical, back off further rather than giving up outright. Set a sane internal timeout well inside the 24-hour expiry window (long enough to tolerate genuine platform slowness, short enough that your product does not leave a customer's scheduled post silently hanging), and when you hit it, stop treating the container as pending: surface it as a delayed/failed publish, and let the customer or your own retry logic decide whether to attempt a fresh container rather than continuing to wait on this one.

Do not create a second container for the same content while the first is still in-progress "just in case." That doubles your exposure to whatever is causing the delay and makes it harder to tell, after the fact, which container actually published if both eventually succeed.

If a container genuinely never resolves — it neither finishes nor errors before expiry — that is worth reporting to Meta, but only with evidence attached. Keep the container ID, the exact timestamps of your creation call and every status poll, the raw asset (URL or file) you submitted, and the account/app identifiers involved. A report with a single reproducible container ID and a clean timeline gets taken far more seriously than a description of the symptom.

PostGate tracks each platform destination as an independent target moving through its own status — including a distinct state while media is still being prepared — so a container that is genuinely stuck shows up as a specific target sitting in that state rather than as an opaque "processing" label on the whole post. Delivery logs preserve the timestamped attempt timeline for that target, which is exactly the evidence Meta support asks for if you do need to escalate — you do not have to reconstruct it from your own polling logs after the fact.