Like every good story, a Job Trace has a beginning, a middle, and an end. It follows a print job from the user’s computer (the origin node), through any replication nodes in the Edge Mesh, and finally to a print candidate node that delivers it to the printer.
Along the way, it shows every step, call, and cloud interaction — making it a powerful tool for troubleshooting print issues in Hive and Pocket. Admins and PaperCut Support use the Job Trace to diagnose problems like job delivery failures, slow replication, or blocked communication between nodes.
This article shows you how to find the Job Trace, how to read it, and offers guidance for error messages you might encounter.
For more complex environments, we’ve updated our best practices for super nodes guide to help you identify whether super nodes with local queues will help when the Edge Mesh encounters difficulties due to network segmentation, port, and protocol controls, or device capabilities.
How to find the Job Trace
Looking for the full behind-the-scenes view of a print job? You’ll find it in the Job Trace, tucked inside the Job Log.
-
First, you must
enable Diagnostic mode
to access Job Trace.
-
In the Explore section, click Job Log.
-
Find the job and click the ⋮ to open the Details.
-
Scroll to the bottom of the details, click Diagnostics, then View job trace.
How to read a Job Trace
A Job Trace is broken into four parts:
- Job Id – The upmost section contains a unique identifier for each print job, we’ll ask for this ID when troubleshooting.
- Information – Key print job details, like the printer name, print status, printing edge node, and edge node candidates.
- Highlighted issues – Any issues during the job’s journey.
- Job Trace details – The full print workflow, from submission to release. This includes the three major steps: submission, replication, and release.
Stages of a Job Trace
Here’s what the job trace shows at each print stage:
Submission | Replication | Release |
| 
| 
|
A user prints from their device, the job is analyzed, and the job is sent securely to local Edge Node or Cloud Node (if enabled).
A successful submission is confirmed when the trace shows the Job status changed to pending-release, indicating the job is securely held in the user's queue. | After submission the job is distributed from the first Edge Node to its peers on the local network.
When the Cloud Node is enabled replication happens after the user releases the job, and the data is copied from the cloud down to the printing Edge Node.
During this time, the trace should log Assigning processor candidates to the job. Success is marked with the line Job status changed to assigned. | Triggered by the user releasing the job at the printer, the local Edge Node sends the job to the physical printer using a defined print method (like IPPS or RAW/9100) with the message Job status changed to printing
WhileJob status changed to printed tells us the print job was sent to the printer without error. |
Highlighted Issues
This section provides an overview of the most commonly reported errors presented in a table format. For each Highlighted Issue, you’ll find a concise explanation of its meaning, as well as practical steps you need to take to resolve the problem.
documentcheck.inaccessibleThis highlighted issue means the Edge Node which was selected to forward the print job to the printer was not able to retrieve the print documents. The print job was not accessible from either the Cloud Node (if enabled) or from another Edge Node in the mesh. Possible causes: This message is logged when one candidate edge node cannot retrieve the print documents, however for printing to be successful only one edge node needs to be able to print the job. The print job was not accessible from either the Cloud Node (if enabled) or from another Edge Node in the mesh. This might be the case if the user’s computer is not in the same network as the edge mesh and the Cloud Node is not enabled. Port 9264 is blocked between subnets or VLANs, preventing replication between Edge Nodes. The job file is too large to replicate. By default, the limit is 500 MB for print jobs replicated locally, and 200 MB for jobs replicated via the Cloud Node.
Recommendations: Check other highlighted issues first — If there are other highlighted issues, this may not be the primary problem. Enable the Cloud Node — It helps avoid network limitations by replicating jobs through the cloud, facilitating printing even if users are outside the network. Test port 9264 — which is required for connectivity between the user’s computer and an Edge Node with access to the printer. From an affected user’s device, use a command like:
Test-NetConnection -Port 9264 -ComputerName <other-node-ip> Consider job sizes — If large jobs consistently fail to replicate, contact PaperCut Support to discuss increasing the limit.
|
jobrouter.assignprocessor.noEdgeNodeCanPrintTheJobThis highlighted issue, accompanied by the phrase “there are no printable edgenodes” means the job router couldn’t find an Edge Node capable of printing the specific job (e.g., no Edge Node online with access to the target printer or the right type of queue). Possible causes: The print job is from a mobile device (Chrome or iOS) which require local queue delivery, but no queue exists which points to the printer. The printer is offline. The printer’s IP address has changed but hasn’t been detected by a scheduled scan yet. Edge Nodes cannot reach the printer on the required ports The print queue on the Edge Node is paused or in an error state.
Recommendations: Set up local queue delivery — if printing from iOS or Chrome, ensure one or more nodes are set up in the Edge Mesh which have a local queue set up for the printer. Is the printer online — Try printing directly to confirm. Has the printer’s IP changed — If so, re-scan it in the Pocket/Hive admin console. Check the delivery type — If the printer uses a queue, verify the queue on the printing Edge Node is not paused or in error. Restart the print spooler if needed. Test network access — from the Edge Node to the printer. Use these commands from the Edge Node to test the connection to each port (SNMP/161, IPP/631 or 443, or RAW/9100): Still stuck — See Best Practices for print job delivery in PaperCut Hive and Pocket to ensure there are reliable Edge Nodes which can consistently reach the printer. Consider setting up a printer delivery profile for the site, particularly in complex environments with strict network segmentation.
|
jobrouter.assignprocessor.jobNotPickedUpThis highlighted issue means PaperCut Pocket or Hive tried to assign the print job to one or more Edge Nodes, but none accepted the job with the message “job not picked up by any processors”. This suggests problems with Edge Node availability, network issues preventing the Edge Node from receiving instructions, or Edge Nodes being overloaded, or edge nodes can’t see the printer. Possible causes: Connection issues. High network latency or low bandwidth between your site and the PaperCut Cloud. Performance problems. Edge Nodes are online but under heavy load (e.g. high CPU), and don’t respond to the job request. Ports blocked. Edge Nodes can’t connect to the MQTT network (used to coordinate job delivery).
Recommendations: Ensure reliable communication to the MQTT network — Some customers have let us know that disabling SSL packet inspection resolved this issue. Make sure candidate Edge Nodes (or Super Nodes) are not resource-constrained — (e.g. high CPU or limited memory). Try restarting the node. Set up a printer delivery profile — to help guide the job through specific reliable printing clients on your network. See: Configuring Print Delivery profiles. We recommend this over our old advice of setting up a Super Node.
|
edgenode.processor.print.actionFailureThis highlighted issue indicates that the Edge Node failed to send the print job to the physical printer. It often comes with a sub-error that tell us why it failed (such as edgenode.processor.print.actionFailure.ippCreateJobFailed). Possible causes: The root cause of this error message, is dependent on which Print Delivery Protocol is being used to send the job to the printer. Local queue delivery - This happen because of a problem with the print queue on the Edge Node. IPP (Internet Printing Protocol) - PaperCut Hive or Pocket is unable to communicate with the printer using IPP, for example the printer is busy and is not accepting IPP jobs. Raw Printing: 9100 - because of network, firewall, or other reasons the printer may not be reachable on port 9100.
Recommendations: Look for a sub-error with more detail: .socketConnectionTimeout (unable to establish connection), .socketWriteFailed (the connection was abruptly closed), .ippCreateJobFailed (IPP protocol issues), .jobStopped (job canceled at the printer), .jobTimeout (printing took too long). Configure print queues in Pocket/Hive — when you set up a print queue in Pocket or Hive which uses a manufacturer’s driver, that can sidestep many printing pitfalls. Once you do this, PaperCut will default to using the OEM driver as the primary print delivery method. See: Creating and deploying PaperCut print queues and drivers. Set up a printer delivery profile — to help guide the job through specific reliable printing clients on your network. See: Configuring Print Delivery profiles. We recommend this over our old advice of setting up a Super Node.
|
edgenode.processor.print.actionFailure.jobStoppedThis highlighted issue indicates the print job was halted on the printer, possibly due to a printer error, a user intervention, or a specific printer state. Possible causes: This error might be expected if a print job was cancelled by a user at the device. A problem with the printer such as a paper jam, causing an error in the print queue.
Recommendations: Ask the user — check with the user to ask whether they intentionally canceled the job at the printer. Check the printer — to see if there was some condition that prevented the device from printing the job such as a paper jam. Restart the printer if needed. Test the local queue — If printing via a local queue on an Edge Node, log onto the printing Edge Node and open Print Management Console on Windows. Ensure a Windows test page can be sent to the printer successfully.
|
edgenode.processor.print.actionFailure.socketWriteFailedThis highlighted issue means the client started a connection with the printer, but had a problem trying to write (send) data. Possible causes: The printer (or a network appliance between the edge node and printer) abruptly closed the connection while data was being written. Network interruption during data transmission. A network appliance, like a firewall or proxy terminated the session mid-transfer.
Recommendations: Network trace — Use command line tools like traceroute to examine the hops between the Edge Node and printer to understand the network path. Investigate each hop — Ask if any of the hops between the Edge Node and the printer might be filtering or blocking network traffic. Test IPP printing — We've noticed that not all printers support IPP equally well, especially during batch printing. If the print method was IPP, we sugguest testing the printer using the method documented here: "Some jobs failed to print. Try again" error message.
|
edgenode.processor.print.actionFailure.ippCreateJobFailedThis highlighted issue means that something went wrong with sending the job to the printer using the IPP protocol.
Possible causes: We’ve found that specific printers advertise IPP support but may have issues with multiple concurrent print jobs (batch printing). When this happens certain printer models stop accepting jobs. Although IPP has been around as a protocol since 1999, it has not been as widely implemented as RAW/9100. This means it has not been as thoroughly tested.
Recommendations: Narrow down the problem —Determine if this only affects specific printer models Upgrade the firmware — Work with your copier dealer to upgrade the firmware on these devices to the latest recommended version from the manufacturer. Configure print queues in Pocket/Hive — when you set up a print queue in Pocket or Hive which uses a manufacturer’s driver, that can sidestep many printing pitfalls. Once you do this, PaperCut will default to using the OEM driver as the primary print delivery method. See: Creating and deploying PaperCut print queues and drivers.
|
edgenode.processor.print.actionFailure.jobTimeoutThis highlighted issue means that the job started sending to the printer but either took too long to print or there was no confirmation of successful delivery. Troubleshooting will depend on whether the job was delivered via a print queue or directly to the printer. Possible causes: Recommendations: Test the local queue — If printing via a local queue on an Edge Node, log onto the printing Edge Node and open Print Management Console on Windows. Ensure a Windows test page can be sent to the printer successfully. Restart the spooler — If the print queue on the Edge Node is in error, try clearing the print job by restarting the print spooler (Windows) or CUPS (macOS and Linux). Check the printer — Make sure the printer hardware is not in an error state, like low toner.
. |
printercheck.unreachableThis highlighted issue means the Edge Node cannot establish basic communication with the printer. This is a general "unreachable" error that could stem from network problems (firewall, routing), the printer being powered off, or the printer not responding to the Edge Node's checks. Possible causes: This error may be logged even when the job prints successfully. Sometimes the printer is simply unreachable because SNMP on port 161/162 is blocked or the SNMP community string on the printer is not public, but the job will still print. The edge node or super node cannot reach the printer on the network (e.g., due to network segmentation, firewall rules, or the printer being offline). This could be because users and devices are on separate subnets, preventing proper communication. Or network ports are blocked, preventing the edge node from accessing the printer. The printer is not available or is in an error state.
Recommendations: Check SNMP - when SNMP is blocked, print jobs may still go through, but PaperCut Hive and Pocket may not be able to fetch the toner levels of the printer or the Page Meter Count of the printer on the Analytics tab may not be current. For tips on troubleshooting SNMP connectivity, see: Why can’t I find my printer in the PaperCut Hive or Pocket admin console? Check connectivity — Ensure that the printing edge node or super node can reliably reach the printer on the network. Is the printer online — Confirm that the printer is online and not in an error state. Test the ports — Check that necessary ports (such as 9100 for manufacturer drivers or 443 for IPPS) are open and accessible.
|
Printercheck.unreachable.cmdexecutiontimeoutThis highlighted issue means the Edge Node was previously able to see the printer, accepted the job to print, but failed to query the printer using IPP over port 631 or 443.
Possible causes:
Recommendations: Test the ports — Verify the Edge Node is online and can reach the printer over the required ports (9100 for manufacturer drivers, 631 for SNMP, and 443 for IPPS) Configure print queues in Pocket/Hive — when you set up a print queue in Pocket or Hive which uses a manufacturer’s driver, that can sidestep many printing pitfalls. Once you do this, PaperCut will default to using the OEM driver as the primary print delivery method. See: Creating and deploying PaperCut print queues and drivers.
|
Other Job Trace messages
These messages don’t appear in the Highlighted Issues, but we still get questions about them.
Failed to update job state: job state transition not allowedThis message does not indicate a problem and is safe to ignore. When you release a print job, PaperCut Hive asks multiple Edge Nodes to print the document. Whichever Edge Node responds fastest wins the opportunity to print the job. The message "failed to update job state: job state transition not allowed" just shows that another, faster Edge Node is in the process of printing the job. Put another way, this message is saying says "No, you can’t move a job back from printing to released, it’s already happened".
 Recommendations: This is normal behavior in the PaperCut Hive print workflow and doesn't indicate a problem with your print job or system. |
routing tasks were not created for job(s), skipping call to statemachineThis error may indicate a problematic edge node failed to analyze the print job and the job failed to move beyond the analysis task. When the user goes to release their job at the copier, the job doesn’t appear in the release list.
If the job is released using the mobile release app, the release will fail with the following error: 
|
Troubleshooting using a Job Trace
The first thing to establish in Job Trace is whether the failing jobs have a common edge node that was part of submission or replication.
The problematic edge node is often the one that submitted or first touched the print job. After you find the offending edge node, set it to passive:
- In the PaperCut Hive admin portal, under Edge Mesh, find the edge node.
- Click on the 3 dots menu and select Demote.
Setting it to passive isn’t the final fix, however it can help to buy some time while figuring out what may be an issue with the edge node or the network.
Comments