How to Know If a Cron Job Silently Stopped Running

A backup runs every night. A report arrives every morning. A synchronization task keeps two systems aligned. Because these jobs usually work, it is easy to assume they are still working today. Then someone notices stale data, and the last successful run turns out to have been several days ago.

The difficult failure is not always a loud exception. Sometimes there is no new event at all. Reliable monitoring needs to notice that absence, not just collect errors when something happens.

Cron jobs can fail silently

Cron starts commands according to a schedule. That does not prove the command completed, or that its output was useful. A scheduler log might show that a script launched even though the script immediately failed to connect to its database.

An application can also exit successfully without doing the intended work. An export might create an empty file, or a script might catch an exception and return zero. Decide what success means before choosing a signal: for a backup, that could include checking that an artifact exists and can be read.

Why checking logs manually is not enough

Logs explain what happened during an execution. They do not automatically tell you that an execution never happened. If nobody looks for a missing line, a stopped job can remain unnoticed.

Manual checks also depend on memory and availability. The person who usually checks a dashboard might be away, and the machine holding the logs might be the machine that failed. Keep logs for diagnosis, but use an independent signal to decide when someone needs to investigate.

Common failure patterns

Start with the failures that are easiest to overlook:

• A different execution environment. A command that works in your terminal may depend on a working directory, executable path, or credentials that the scheduled process does not have. Use explicit paths and deliberate configuration.
• A deployment that changes the schedule. Replacing a server or container can leave the application healthy while its scheduled task is missing.
• A dependency that stops responding. Database connections, network calls, and locks can leave a process running indefinitely. A process being alive is not evidence of progress.
• Overlapping executions. If one run takes longer than the scheduling interval, the next may compete for the same files or resources. Skipping overlapping work also changes the completion pattern you should expect.
• Time and calendar assumptions. Timezones and daylight saving behavior depend on the scheduler implementation. Check your scheduler's documentation, especially for jobs scheduled near a clock change. The crontab manual documents schedule and environment details for its implementation.

When investigating, check the installed schedule, process exit status, output freshness, and recent configuration changes. Do not assume a successful manual rerun explains why the scheduled run was missed.

How to detect missing runs

Record a timestamp after each successful completion. An independent checker compares that timestamp with the expected next completion time, then alerts after an additional grace period.

For a roughly hourly job, the last successful completion plus one hour gives a simple estimate. A ten-minute grace period allows for ordinary variation. That is an example, not a universal setting: choose a delay that matches the job's normal runtime and the cost of stale results.

Calendar schedules need more care. A weekday-only job should not trigger a weekend incident just because a fixed interval expired. Irregular or event-driven work may need an explicit deadline instead of interval-based monitoring.

Also handle the first run. With no successful completion yet, there is no useful interval to infer. Check that the integration produces its first signal, and define an initial deadline separately if you need immediate coverage. Never treat an untested monitor as proof that a job is protected.

Simple monitoring approaches

Check the freshness of the result

For an export, inspect the latest file or successful database checkpoint from a separate system. This measures useful output rather than process activity. Avoid using file modification time alone if a failed run can touch an existing file without producing a valid result.

Send a completion ping

A lightweight alternative is an HTTP request after successful work. A shell wrapper can make the ordering explicit:

#!/bin/sh
set -eu

cd /srv/reporting
/usr/bin/python3 generate_report.py

# Load this private URL through your normal job configuration.
: "${MONITOR_PING_URL:?Set MONITOR_PING_URL}"
curl --fail --silent --show-error --max-time 10 "$MONITOR_PING_URL"

In this wrapper, a failed Python command stops execution before the ping. The curl options make HTTP errors visible, keep useful error output, and bound the transfer duration. See the curl manual for exact option behavior.

A failed ping does not necessarily mean the report failed. The work may have completed while the monitoring request encountered a network problem. Investigate the two separately, and do not automatically rerun non-idempotent business work just because its completion signal failed. Keep the ping URL private, since someone who knows it may be able to send misleading signals.

Test the missing-run alert

Use a disposable job to test the full path:

1. Send enough successful signals to establish its expected behavior.
2. Stop sending signals and wait beyond the deadline and grace period.
3. Verify that the right person receives an actionable alert.
4. Restore the job and check that monitoring shows recovery.

Choose an alert channel someone actually checks. Include the job name and last successful completion, and document where to look next. Avoid sending repeated alerts every minute for one unresolved incident; that makes important notifications easier to ignore.

How Runvera helps

Runvera provides completion-ping monitoring for recurring background jobs. Create a Job, call its private Ping URL after successful work, and Runvera learns an interval from the received pings. Jobs remain in Learning until enough pings are available; manual interval and grace overrides are available when needed.

Late monitoring can then alert you when expected signals stop arriving. It complements logs and output checks rather than proving business correctness. Start with one predictable job, verify the alert path, and expand from there.

Want a simple place to start? Try Runvera to monitor background jobs and get alerted when they run late or stop reporting. Send a ping. We'll learn the rest.