Logs probably go to syslog, which varies depending on what syslog daemon is involved and how that is configured to log, start with
grep -r cron /etc/*syslog*
to find where and what is going on on the system, or per derobert under
systemd the relevant command is
journalctl -b 0 _SYSTEMD_UNIT=cron.service
Adding a test cron job that touches a file (ideally not in
/tmp, unless the vendor makes that per-user private, for security reasons) should also confirm whether cron is working or not, just be sure to eventually remove the test cron job before it fills up a partition or something silly.
Other usability and security pointers: some cron daemons can run scripts directly, in which case you can just copy the script into
/etc/cron.daily, though this may not suit something that you do not want to run (with everything else!) at exactly the top of the hour.
root running a script under a user's home directory could be very bad, as a compromise of that user account could then be leveraged to root access, or the script could needlessly fail if the home directory is on NFS or encrypted; move the script elsewhere to avoid this (
/root/bin, or somewhere under
/opt depending on the local filesystem preferences).
Even more pointers fall into the realm of shell script debugging, mostly to note that cron is not the shell; use
set to see what is set under cron, check that
PATH is correct, and etc. (One old and horrible linux kernel bug involved java daemons crashing but only if they were run from cron; that was fun to debug...)