The & backgrounds well except for programs that come back requiring console interaction later on (for example, an "apt -y update &" that eventually enters the STOP state since it's wanting to prompt the user a "really really force?" question much later....when no one is watching anymore).
To plug that hole and inform the process a terminal will really never never become available to it, I append a <&- to some of my commands, completely detaching them from the active terminal telling them STDIN is no longer possible. Make sure /bin/bash is your shell if you use that though. The script will carry on logging any errors related to no pseudoterminal being available on which to cast any prompt.
`./runme.sh &> runme.log <&- & disown`
is my ultimate way of disassociating from current terminal session. Both STDOUT and STDERR get logged to runme.log, it won't matter if your console or shell terminate sooner or if you logout/su to a different account (no terminal garbage from runme), and thanks to disown even the parent-child PID relationship is removed.
UPDATE: even with that I've had trouble with a semaphore associating it with the name of the original parent, so now I recommend instead:
at now <<< "(cmd1; cmd2; etc.) &> logfile.log"
Of course, remove the &> if you want to get emailed the output from CRON, or redirect it all to /dev/null instead of a file.