Well there is that well known tale about the sparrow sharpening his beak on a mountain...
Perhaps not that long, but too long. I think it may vary, depending on factors that I cannot begin to guess at.
I suppose I could try some experiments...
No, I don't think so...
For example in end script
M190 R45 - tells printer to wait till bed temp gets to r45
M140 S0 ; turns off bed straight away
Often used with LEDs, or using part fan to cool bed etc.
If it's a blocking temperature issue you could enable the option EMERGENCY_PARSER in marlin and it will actually kill the temp on cancel from octoprint even if it hasn't been reached.
Which log(s) would you like?
Because you raised in general rather than get help you did not get the template.
These messages are all over the place:
| Recv: // Heater extruder not heating at expected rate
| Recv: // See the 'verify_heater' section in config/example-extras.cfg
| Recv: // for the parameters that control this check.
| Recv: //
| Recv: // Once the underlying issue is corrected, use the
| Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
| Recv: // config, and restart the host software.
| Recv: // Printer is shutdown
| Recv: !! Heater extruder not heating at expected rate
| Recv: // Heater heater_bed not heating at expected rate
| Recv: // See the 'verify_heater' section in config/example-extras.cfg
| Recv: // for the parameters that control this check.
| Recv: //
| Recv: // Once the underlying issue is corrected, use the
| Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
| Recv: // config, and restart the host software.
| Recv: // Printer is shutdown
| Recv: !! Heater heater_bed not heating at expected rate
This is printer related. You may check the cables and connectors. Maybe the power supply is insufficient. Please also share the serial.log. (this maybe has to be enabled)
And BTW: What printer are you using?
Nah, they're all in the file. 
Quite possibly, but this is not the problem that I came here with.
As you say, this has to be enabled... I'll maybe get back to you with that.
It's an Anet A8 chassis with a TriGorilla board.
Quite possibly, but this is not the problem that I came here with.
It might be though - if your printer is waiting for a temperature change, it'll be stuck in a single line of gcode. When you press "pause" or "stop" in Octoprint, it just stops sending any further gcode to the printer. If the printer is still executing the last few lines sent, then that could take a while if one of those steps is to wait for something that's taking longer than expected.
Honestly, if you've got a power supply issue, it's probably the cause of a world of issues that you may have been ignoring up to now. A power supply issue makes you somewhat unique. Your issue is somewhat unique. Taking away your uniqueness in one area may well not fix it in another, but we can't know for sure until you've done it.
Why would it be waiting for a temperature change?
Obviously, it might be, if that was the stage of the print that it is at, but it isn't usually, and it certainly wasn't on the occasion that it took five minutes.
If it can force through an emergency stop, then why can't it force through a cancellation?
@Hairyloon, we wouldn't have to bicker about what the printer is or isn't doing if you would take the time to reproduce the problem with the serial.log enabled and then upload it.
What the printer is doing a the end of a print job is determined by the end code added by the slicer. Since you haven't bothered to tell us which slicer you are using we can't even guess what that might be and we shouldn't have to. Provide us with a copy of the end code from the slicer. Alternatively, provide us with a copy of the gcode for a small part that exhibits the problem.
The more details you provide, the better help we can give you.
Depends on your firmware, it's capabilities, and buffer. For example there is the EMERGENCY_PARSER in Marlin that if that is enabled (disabled by default) it can break through waiting for temperatures, etc.
If it was getting to the end of the print job, then I wouldn't be cancelling it would I?
If it was hanging on the last few commands of the Gcode this could be determined from the serial log and the GCODE. Without it is guess work.
There are definitely gcode commands that will cause the behaviour you are seeing. But it could be something completely different.
I mentioned above I have command I put in that cause it to wait, this also effects cancel but emergency stop will work.
It's hardly an argument to dismiss a suggestion that is self evident nonsense.
Thank you for your contribution and my sincere apologies for bruising your ego.
I've enabled the serial log, but I've not had the problem since.
But surely cancelling the print should interrupt the G-Code?
Unless, as we have already discussed, it is executing a command that takes a while, then the only G-Code that matters should be the cancel scripts in Octoprint.
The difference is the interuptability.
If you have a job printing and click cancel it will only cancel once these commands are cleared. Where as an emergency stop (with the relevant firmware parameter) will stop it dead.
But even if not the issue the serial log shows what was happening at the time, or the last thing to happen. Otherwise unless someone else has had the same issue it is hard to know what the issue is.
It is enabled now. When it happens again, I'll get back to you with the logs, though I'm starting to think it more likely that the issue is with the Firmware: I'll raise the point with them.