Octoprint sitting at 96% when print complete

What is the problem?
The print job runs fine and Octoprint runs normally throughout. When the print job is finished, Octoprint sits at 96% and never finishes. The print completes correctly. If I refresh the browser, Octoprint shows ready to print. I have tested on Brave, Firefox and Chrome. Same result.

What did you already try to solve it?
Rebuilt Octoprint. Was fine for a bit and then started the same issue again.

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
Ocotprint version: 1.4.0
OctoPi version: I downloaded the lastest from the site: 0.17.0
Printer: Maker Select V2.1
Firmware TH3d U1.R2.15
OS: Windows 10 Pro (Microsoft Surfave 3)
Broswers: Brave, Chrome, Firefox. All latest releases
Pi: RPi 4B 2GB
octoprint.log (665.5 KB)

I might guess that there is some sort of JavaScript error (seen in your browser's Developer Console area) which might prevent the front-end from refreshing state.

Try in Safe Mode and see if it's happy.

Do you have octolapse running?

Ok I will give it a go. Perfect timing..I have a print running...should be done in a few hours.

Octolapse is not running or loaded

Feel free to use something like Postman to craft a GET message to the REST API and ask the printer for its status. You're interested in progress.

If you're a fan of NodeJS then octo-client's examples include stuff like this.

Nothing showed up in the console...no errors.

This is the last set of commands from the terminal window besides the temps dropping now that the run is complete.

Changing monitoring state from "Printing" to "Finishing"
Send: N116633 M400*23
Recv: ok
Changing monitoring state from "Finishing" to "Operational"

So the job is finishing from what I can see however the browser is not updating as expected.

I have attached a screenshot of the plugins I have installed.plugins

Pull the mask off the bed, restart Octoprint in Safe Mode and print another. Query remotely if you'd like.


  • Verb = GET
  • URL = http://octopi.local/api/job
  • Headers tab
    • X-Api-Key = whatever is in your OctoPrint's ~/.octoprint/config.yaml -> api -> key
    • Content = application/json
  • Body tab: Select None
  • Press the SEND button and read the response

If you sliced using the .ufp format then you might need to either extract the gcode file out of that or reslice without the UFP format (since Safe Mode would keep that from running). But it's also possible that the UFP plugin has already extracted it and the gcode file is what's stored now in your ~/.octoprint/uploads folder. This appears to be what it does.

Ok I will give it a go after work today. Thanks!

1 Like

I have this issue, CR-10S Pro, for weeks now. and now my Creality CR-6 SE is doing it!
Always print via Upload to Files section.
Did you ever resolve this?

Have you tried running in safe mode? Have you checked the browser console for errors?

How does you End Gcode look like?

G91 ;Relative positioning

G1 E-2 F2700 ;Retract a bit

G1 E-2 Z0.2 F2400 ;Retract and raise Z

G1 X5 Y5 F3000 ;Wipe out

G1 Z10 ;Raise Z more

G90 ;Absolute positioning

G1 X0 Y{machine_depth} ;Present print

M106 S0 ;Turn-off fan

M104 S0 ;Turn-off hotend

M140 S0 ;Turn-off bed

M84 X Y E ;Disable all steppers but Z

M300 P500

G4 S1000

M300 P100

G4 S500

M300 P100

Send: N37406 G1 E-2 F270055
Recv: ok
Send: N37407 G1 E-2 Z0.2 F2400
Recv: ok
Send: N37408 G1 X5 Y5 F300068
Recv: ok
Send: N37409 G1 Z10
Recv: ok
Send: N37410 G9017
Recv: ok
Send: N37411 G1 X0 Y255
Recv: T:206.87 /207.00 B:60.00 /0.00 @:72 B@:0
Recv: echo:busy: processing
Recv: ok
Send: N37412 M106 S0100
Recv: M106 P0 S0
Recv: ok
Send: N37413 M104 S0
Recv: SetNewScreen: 36
Recv: SetNewScreen (saving): 36
Recv: //action:notification CR6Comm-Rel6.1 Ready.
Recv: ok
Send: N37414 M140 S096
Recv: //action:notification CR6Comm-Rel6.1 Ready.
Recv: ok
Send: N37415 M84 X Y E
Recv: T:206.87 /0.00 B:59.97 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: T:207.03 /0.00 B:59.79 /0.00 @:0 B@:0
Recv: ok
Send: N37416 M300 P50098
Recv: ok
Send: N37417 G4 S1000
Recv: T:206.87 /0.00 B:59.79 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: T:206.25 /0.00 B:59.60 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: T:204.58 /0.00 B:59.54 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: T:203.09 /0.00 B:59.38 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: T:201.08 /0.00 B:59.19 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: T:199.03 /0.00 B:59.11 /0.00 @:0 B@:0

Is this the printer that requires special commands in OctoPrint's gcode settings to tell the display what the current process is doing? Something like what's documented on the jyers wiki here.

Everything looks OK to me in that screenshot...? I think I can see the issue you are mentioning, with the delay before print complete.

If you want this to be looked into further, then provide the full octoprint.log & serial.log as files, downloaded straight from OctoPrint.

and also try the print running OctoPrint in safe mode. could also be a plugin interfering.

octoprint-logs-cr-6se-serial.zip (726 Bytes)
octoprint-logs-cr-6se.zip (670.9 KB)
Safe Mode does not prevent this issue. Thanks in advance,

I completely wiped the CD card and reinstalled Octoprint, and restored from a 1.1MB backup, so just the plug-ins replaced, all files lost, still did it.
Rules out OctoPrint I'd say.