Captura de la salida, MAILTO y lista de comprobación de registros
Cuando cron falla, lo normal es que pase por alto el fallo en silencio. Si la expresión es correcta según esta herramienta pero la tarea aún así no se ejecuta, es muy probable que el problema no sea la expresión, sino el entorno de ejecución. A continuación resumimos, en orden, cómo acotar la causa.
Guarda la salida en un archivo. Por defecto, cron envía por correo la salida estándar y el error estándar de la tarea, pero si el correo no está configurado, se pierden sin más. Si añades >> /var/log/myjob.log 2>&1 después del comando para guardar tanto stdout como stderr en un archivo de registro, podrás comprobar de inmediato qué ha ocurrido.
Recibe avisos con MAILTO. Si pones MAILTO="you@example.com" al principio del crontab, la salida y los errores de la tarea se envían a esa dirección. Es la salvaguarda más sencilla para evitar los fallos silenciosos. Al contrario, si no quieres recibir correo, déjalo vacío con MAILTO="".
Consulta los registros del sistema. En las distribuciones tipo Debian y Ubuntu, con grep CRON /var/log/syslog, y en entornos systemd, con journalctl -u cron (o crond), comprueba si cron ha disparado la tarea. Aquí la distinción importante es que 'haber intentado ejecutarla' y 'que el script haya tenido éxito' son cosas distintas.
Por último, una lista de comprobación de las causas más comunes. ① ¿Has indicado todos los comandos y archivos con ruta absoluta? ② ¿Has declarado el PATH necesario en el crontab? ③ ¿Tiene el script permiso de ejecución (chmod +x)? ④ ¿Has puesto la tarea en el crontab del usuario correcto (el crontab de root y el de un usuario normal son independientes)? Comprueba estas cuatro cosas y vuelve a validar la expresión en sí con este intérprete.