Find the scheduler that owns the job
Cron and systemd timers both start scheduled work, but their configuration, logging and missed-run behavior differ. Locate the actual crontab or timer unit, the service account, host and time zone before adding another schedule. Running both can duplicate work.
For a systemd timer, inspect the timer and its associated service, including the last and next trigger and the service journal. For cron, inspect the appropriate crontab and scheduler logs. Confirm the scheduler was active and the host clock was correct at the expected time.
Compare the execution environment
Scheduled jobs often run with a smaller PATH and different working directory from an interactive shell. Verify the executable path, required environment variables, file permissions and access to dependent services. Do not print secrets while debugging.
Check how the job handles overlap, downtime and retries. A timer's persistent behavior depends on its configuration and the kind of timer; do not assume every missed run will automatically replay. A task that modifies data should be safe to retry or have a documented reconciliation step.
Test without duplicating production work
Use a harmless test input or a staging environment to run the same command under the same account. Confirm the result, exit status and logs. Add monitoring for missed runs and stale results, not just scheduler process availability.
Document the owner, expected interval, recovery procedure and a safe way to pause the job during maintenance.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.