Your warehouse printer went offline. What should happen to the labels?

A disconnected printer is not one problem. It can mean the printer lost power, the workstation is asleep, the station application stopped, the local network failed, or the building lost internet.

The label decision is separate: should new work fail immediately, wait, move somewhere else, or expire?

The wrong universal answer creates either lost work or a burst of stale labels when the connection returns.

First, separate a short interruption from a long outage

A station reboot during a shift and an abandoned workstation over a weekend should not have the same business outcome.

Define operational windows for each workflow:

• brief: the label remains valid and can print automatically after reconnect;
• attention required: the label may still be valid, but an operator should inspect the queue;
• stale: the document must be canceled, regenerated, or routed elsewhere.

These windows come from the business process, not the print platform. A packing slip may remain useful for hours. A carrier label can become wrong after a shipment is voided or repurchased.

Persist the instruction before attempting delivery

If a print call returns an error simply because the station is offline, every caller must build its own retry queue and reason about whether an earlier attempt arrived.

A durable remote job changes the boundary. The API can validate and persist the instruction as pending, return its ID, and wait for the station to reconnect.

Your application should retain that job ID on the shipment or document record. It is the handle used to inspect, cancel, and reconcile the instruction later.

Do not create replacement jobs while the original is pending. That turns a connectivity incident into duplicates.

Give operators visibility before recovery

An automatic reconnect is helpful after a five-minute interruption. After several hours, it can release a wall of labels whose orders were already handled another way.

The recovery view should answer:

• how long the station has been offline;
• how many jobs remain pending;
• the oldest and newest pending timestamps;
• which document purposes are in the queue;
• whether any source documents were superseded or voided;
• which alternate path operators used during the outage.

Make that information available before restarting or reauthorizing the station after a long outage.

Cancel stale work while it is still pending

Pending is the safe cancellation boundary because the job has not been dispatched to the station.

Once dispatch begins, a cancellation response cannot honestly guarantee that the local machine did not receive the job. At that point, the recovery process must observe the existing job rather than pretend it was stopped.

For each pending record, compare the original document version with current business state. Cancel it when:

• the shipment was voided;
• a new carrier label replaced it;
• the order moved to another location;
• an operator already printed it through a controlled fallback;
• the document exceeded its business validity window.

Keep the canceled record. It explains why the old instruction did not print.

Recover in creation order—but question whether that order is still useful

A queue normally dispatches oldest work first. That preserves request ordering across a short interruption.

After a long outage, oldest-first may prioritize the least relevant documents. The answer is not to reverse the queue silently. It is to remove stale work and then allow the remaining valid records to resume in their original order.

If a workflow needs priorities, model them deliberately at the application level rather than relying on emergency manual sorting.

Distinguish rerouting from retrying

Routing a shipment to another printer is a new operational decision. Repeating the same API request is a transport retry.

If the original job is still pending and you decide to print elsewhere:

1. cancel the original job;
2. create a new instruction for the alternate printer;
3. record the relationship and reason;
4. make the new idempotency identity explicit.

Do not send the same idempotency key with a different printer or payload. A conflict is the correct response because the business instruction changed.

Plan the local failure too

The station can reconnect while the physical printer remains unavailable. Cloud connectivity is only one segment.

Test what the local operating system reports when the queue is paused, the device is unplugged, stock is missing, or the driver rejects content. Some conditions produce a clear command failure. Others are accepted by the spooler and fail later outside the station's observable boundary.

Operators need a local checklist as well as a cloud status:

• confirm the correct device and stock;
• clear paused or stopped local queues;
• inspect for already-spooled duplicates before resubmitting;
• scan a test label after media or printhead work;
• reconcile the remote queue before returning the workcell to service.

Run a recovery drill before peak volume

Create a safe test lane and exercise this sequence:

1. stop the station;
2. submit several labeled test jobs;
3. cancel one as stale;
4. restart the station;
5. verify only the remaining jobs print, in order;
6. restart again and confirm completed jobs do not intentionally print again;
7. map each physical test label back to one remote job ID.

The drill should include operations, not only engineering. The code can preserve a queue while an unclear recovery procedure still produces duplicates.

RocketPrint's offline queue model provides the durable mechanism. Your team supplies the validity windows, rerouting rules, and operator decision that determine which labels should still become paper.