Find out what happened before printing again.

1. Find the request

Open the job list in Print Center or the print archive. For work sent through an Automation Service, open that service's detail view and inspect jobs and recent activity. Note the request identifier, label version, inputs, target, quantity and message.

A direct Center-to-printer request has its own result and archive record; it does not create a Runner job row. Use the view that belongs to the request's actual path.

2. Read the reported state

Reported state	What it tells you	Next action
Accepted or queued	The system accepted or queued work. It has not established delivery.	Inspect the service connection and later job events before submitting again.
Sent	The stream was sent, or a local queue accepted it, without device confirmation.	Check the physical output and queue. Do not assume that no label was produced.
Confirmed	A capable target acknowledged the request.	Check physical content and quality where required. Confirmation does not inspect a barcode or media alignment.
Held or unknown	The system cannot establish the print outcome.	Investigate the printer, queue and output before making a replacement decision.
Failed or refused	The attempt failed or a rule rejected it. The accompanying code identifies the reason.	Resolve the reported problem and inspect the recorded delivery information before repeating.

3. Locate the interruption

• At the printer: check power, media, connection and device messages.
• At a local queue: ask the station owner to check the queue on the service machine and access for the service account.
• At the Automation Service: check whether it is running, connected and has applied the required documents.
• Between the service and Center: inspect connectivity separately from printer reachability. Local work depends on what was already deployed and which data sources remain available.

If you need help, pass the request identifier and message to your administrator. This lets them investigate the same attempt rather than creating another one to see what happens.

4. Make an explicit recovery decision

For work that has not started, an available cancel action may stop the Runner job if its state and connection allow it. Read the cancellation result. A cancellation request cannot retract output already produced.

For an uncertain outcome, establish whether the label is present, usable or needs replacement. Use the available repeat action only when the responsible person has decided another request is needed. Repetition creates new work; reconnecting a printer does not resolve the uncertainty of an earlier attempt.

If another printer is needed, have the administrator select and check the destination, media and label suitability for the new request.

5. Close the loop

Review later job events and the archive after recovery. Keep the original and replacement request identifiers together in your incident record. This explains what was known when the replacement was requested.

Understand local continuity → · Check the printer path → · Administration guide →