DEV Community: quietpulse

Cron Job Not Running? A Practical Debug Guide for Production

quietpulse — Sat, 11 Apr 2026 05:13:03 +0000

If you are dealing with a cron job that should have run by now but did not, you need a real cron job not running debug process, not guesswork.

This is one of the most frustrating production problems because nothing looks obviously broken. Your app is up. The server responds. Dashboards are green. But some scheduled task, backup, sync, invoice generation, cleanup, email digest, simply did not happen.

The problem

A cron job not running is different from a cron job running and failing.

If the script starts and exits with an error, you usually have logs. If the job never runs at all, you often get almost nothing.

Typical symptoms:

a report did not arrive
backups were not created
invoices were not generated
cleanup stopped
a sync job did not run
the script works manually but not on schedule

Why it happens

1. The schedule is wrong

Cron syntax is easy to misread. Timezone confusion, wrong frequency, and editing the wrong crontab are common causes.

2. Cron runs in a different environment

Cron often has a reduced PATH, missing environment variables, and a different working directory.

/usr/bin/python3 /opt/app/sync.py

Using absolute paths is much safer than relying on shell defaults.

3. The cron daemon is not active

Sometimes the scheduler itself is stopped, never started after reboot, or missing from the runtime environment.

4. Paths or permissions changed

Deployments can move scripts, virtualenvs, binaries, or log locations.

5. Output is discarded

This makes debugging much harder:

0 * * * * /opt/scripts/run-report.sh >/dev/null 2>&1

Why it's dangerous

A cron job that does not run is dangerous because the damage is delayed:

stale data
missed backups
broken customer workflows
growing queues or temp files
billing gaps

The worst part is false confidence. Everything else may look healthy.

How to detect it

The best way to detect this is to monitor expected execution.

Ask:

was the job supposed to run?
did cron invoke it?
did it complete?
did it report success?

Heartbeat monitoring helps because a missing success signal becomes the alert.

Simple solution (with example)

A practical checklist:

inspect the correct crontab
confirm cron service is running
use absolute paths
capture output to a real log during debugging
test under cron-like conditions
add missed-run monitoring

Example:

#!/bin/bash
set -e

/usr/bin/python3 /opt/app/daily-report.py
curl -fsS https://quietpulse.xyz/ping/YOUR_JOB_TOKEN > /dev/null

And in crontab:

0 * * * * /opt/scripts/daily-report.sh

If the ping stops arriving, you know the job did not complete successfully on time.

Common mistakes

1. Debugging the script before confirming cron fired

If the scheduler never invoked the command, script-level debugging wastes time.

2. Checking the wrong user's crontab

Very common on shared systems.

3. Assuming manual success proves cron success

Your shell is not cron's shell.

4. Throwing output into `/dev/null`

That removes your fastest clue.

5. Ignoring timezone configuration

The job may be running at a different time than expected.

6. Fixing it once without adding monitoring

That is how the same incident repeats.

Alternative approaches

System logs

Good for confirming trigger attempts, but not enough on their own.

Wrapper scripts with exit reporting

Useful, but you still need missed-run detection.

Framework schedulers

Sometimes better for app-level visibility, but not always right for system jobs.

Heartbeat monitoring plus logs

Usually the most practical combination.

FAQ

How do I debug a cron job that is not running?

Check the schedule, correct user, cron service, command paths, and logs, then test under cron-like conditions.

Why does a cron job work manually but not automatically?

Because cron runs with a smaller environment, different PATH, and different assumptions.

How do I know whether cron actually triggered a job?

Check service status and cron-related logs, and add heartbeat monitoring for future runs.

What is the best long-term fix?

Use explicit paths, clear environment setup, useful logs, and alerts for missed execution.

Conclusion

When a cron job is not running, the fastest fix comes from a checklist, not guesswork.

Confirm the schedule, user, service, and paths, then add monitoring so the next missing run does not stay invisible.

Originally published at https://quietpulse.xyz/blog/cron-job-not-running-debug-guide

Common Cron Job Issues in Production and How to Prevent Them

quietpulse — Fri, 10 Apr 2026 06:29:07 +0000

If you rely on scheduled tasks, backups, reports, sync jobs, cleanup scripts, sooner or later you will run into cron job issues in production.

The hard part is not that cron jobs fail. The hard part is that they often fail quietly. A broken scheduled task can go unnoticed for hours or days while the rest of your app appears healthy.

The problem

Cron looks simple, so teams often treat it as solved infrastructure. Add a crontab line, test once, and move on.

But production adds real complexity:

environment differences
rotated credentials
container restarts
overlapping runs
external API dependencies
logs nobody checks
timezone mistakes

That is why cron jobs break more often than people expect.

Why it happens

1. Cron runs with a minimal environment

A script may work manually but fail in cron because PATH or environment variables are different.

#!/bin/bash
/usr/bin/python3 /opt/app/sync.py

Using absolute paths is much safer than relying on shell defaults.

2. Dependencies change

Databases, APIs, tokens, certificates, and containers all change over time. Cron jobs are often forgotten until one of those dependencies breaks.

3. Logging is not monitoring

This pattern is common:

0 * * * * /opt/scripts/report.sh >> /var/log/report.log 2>&1

Useful for debugging, yes. Real monitoring, no.

4. Schedules are easy to misread

Cron syntax is short, but mistakes happen all the time:

wrong timezone
wrong frequency
duplicate runs across servers
bad assumptions about ordering

5. Jobs overlap

When a task starts taking longer than expected, multiple runs can overlap and cause duplicate work, race conditions, or inconsistent state.

Why it's dangerous

Broken cron jobs create delayed damage:

backups stop
reports go stale
customer workflows fail
billing tasks are missed
bad data spreads quietly

The biggest risk is false confidence. Nothing looks down, so nobody investigates.

How to detect it

The best way to detect cron problems is to monitor successful execution.

A useful question is not “is the server alive?” but:

did the job run?
did it complete?
did it complete on time?

Heartbeat monitoring is a simple answer. Each successful run sends a signal. If the signal does not arrive on schedule, you get alerted.

This catches missed runs, script crashes, removed schedules, dead cron processes, and broken environments.

Simple solution (with example)

Here is a simple pattern:

#!/bin/bash
set -e

/usr/bin/python3 /opt/app/daily-report.py
curl -fsS https://quietpulse.xyz/ping/YOUR_JOB_TOKEN > /dev/null

And the cron entry:

0 * * * * /opt/scripts/daily-report.sh

If the ping stops arriving, something is wrong.

You can use any heartbeat-style monitoring approach for this. The main idea is to detect absence, not just log errors after the fact.

Common mistakes

1. Relying only on logs

Logs help with debugging, but they do not actively alert on missed runs.

2. Monitoring only uptime

A server can be healthy while scheduled tasks are broken.

3. Not using absolute paths

Cron’s environment is limited, so explicit paths prevent avoidable failures.

4. Ignoring overlap

Use locking when a job must not run concurrently.

flock -n /tmp/daily-report.lock /opt/scripts/daily-report.sh

5. No alerting for absence

Missed execution is the failure mode that matters most, so alert on that.

Alternative approaches

Logs

Good for investigation, weak for detecting jobs that never started.

Exit code reporting

Useful if you want a custom internal monitoring flow, but you still need missed-run detection.

Queue-based schedulers

Better observability in some apps, but not always appropriate for system scripts.

Uptime checks

Helpful for websites, not enough for background jobs.

In practice, logs plus heartbeat monitoring is a strong combination.

FAQ

What are the most common cron job issues in production?

Missing environment variables, wrong PATH, expired credentials, overlapping runs, timezone mistakes, and silent failures without alerts.

Why does a cron job work manually but fail in cron?

Because cron runs in a minimal environment. Use absolute paths and define required environment variables explicitly.

Are logs enough for cron monitoring?

No. Logs are useful for debugging, but they are not enough to detect missed runs in time.

How do I stop cron jobs from failing silently?

Use heartbeat monitoring or another execution-based alerting method that detects missing successful runs.

Conclusion

Cron is easy to set up and easy to ignore.

If a scheduled task matters, do not just log it. Make sure you know when it stops running.

Originally published at https://quietpulse.xyz/blog/common-cron-job-issues-in-production

Why Cron Jobs Fail Silently (and How to Catch Them Early)

quietpulse — Thu, 09 Apr 2026 06:24:45 +0000

Why Cron Jobs Fail Silently (and How to Catch Them Early)

If you've ever had a backup stop running, a report fail to send, or a cleanup task quietly die for days, you've already seen why cron jobs fail silently.

That is what makes scheduled tasks dangerous. They usually work in the background, no one looks at them every day, and when they fail, nothing crashes in a visible way. Your app stays online, your landing page still loads, and your health checks stay green. Meanwhile, something important is no longer happening.

A cron job is often responsible for work that only becomes visible after damage is done: invoices were never generated, stale data was never refreshed, users stopped getting notifications, or logs filled up because cleanup stopped last week. By the time someone notices, the real problem is no longer the failed job. It is the pile of side effects that came after it.

In this article, we'll break down why cron jobs fail silently, why this happens so often in production, and how to detect these failures before they turn into support tickets and late-night debugging sessions.

The problem

Cron is simple by design. You define a schedule, point it to a command, and let the system run it on time.

That simplicity is exactly why people trust it too much.

A lot of teams assume that if the cron entry exists, the task is running. But cron only tries to execute the command. It does not guarantee that the task finished successfully, did the right work, or even produced the output you expected.

Here are a few common examples:

A backup script still runs every night, but authentication to cloud storage expired.
A billing sync job starts, then crashes halfway through because of one malformed record.
A cleanup task depends on a mounted volume that was not available after a reboot.
A scheduled script works manually but fails under cron because environment variables are missing.
A container restart removed the cron process entirely, so nothing has run for two days.

In all of these cases, your system may look "up" from the outside. Web uptime checks pass. API endpoints return 200. No obvious alert fires. But an important background process has stopped doing its job.

That is the real issue. Cron failures are often operationally invisible.

Why it happens

There are several technical reasons why cron jobs fail silently.

1. Cron has very little context

Cron runs commands in a minimal environment. That means:

different PATH
missing shell config
missing environment variables
no interactive session
different working directory

A script that works perfectly when you run it manually may fail under cron because it expects variables from .bashrc, a specific current directory, or credentials loaded in a login shell.

2. Output is easy to ignore

Many cron jobs write output to stdout or stderr, but no one actually reads it.

Sometimes the output is emailed locally on the server. Sometimes it is redirected to a log file. Sometimes it is discarded completely with something like:

*/5 * * * * /path/to/job.sh >/dev/null 2>&1

That line is common, and it removes the only immediate signal that something went wrong.

3. "Command started" is not the same as "job succeeded"

Cron considers its job done once it launches the command. But from an operator's point of view, that means almost nothing.

A task can:

exit with an error
hang forever
process partial data
skip work because of bad conditions
silently produce incorrect output

From cron's perspective, it ran the command. From your perspective, the business process failed.

4. Many failures happen outside the script itself

A cron job can fail because of infrastructure around it:

DNS issues
expired credentials
network outages
permission changes
disk full
locked files
missing binaries after deploy
container or host restarts

The script may not be wrong at all. The environment changed.

5. No one notices missing execution

This is the biggest one.

Teams often monitor errors, but they do not monitor absence.

If a cron job is supposed to run every 5 minutes and it stops entirely, there may be no error event to capture. There is just silence. And silence is hard to alert on unless you explicitly design for it.

Why it's dangerous

Silent cron failures are dangerous because they create delayed, messy incidents.

The first problem is hidden operational drift. Systems depend on background work more than most teams realize. Scheduled jobs refresh caches, sync data, clean storage, rotate tokens, send emails, and process queued work. When they stop, the product degrades slowly.

The second problem is false confidence. Everything may look healthy because customer-facing endpoints still respond normally. Traditional uptime monitoring says the service is fine. But reliability is already slipping underneath.

The third problem is blast radius. One missed run might be harmless. Fifty missed runs usually are not.

A failed cron job can lead to:

missing backups
stale analytics or reports
delayed notifications
billing mistakes
failed renewals
unprocessed imports
storage growth from skipped cleanup
inconsistent state across systems

And the longer it goes unnoticed, the harder recovery becomes. Instead of fixing one failed run, you are suddenly dealing with backfills, duplicate processing, customer support, and damaged trust.

This is why cron jobs fail silently matters as an operational question. The issue is not just "a script failed." The issue is that a business process stopped and nobody knew.

How to detect it

The most reliable way to detect silent cron failures is to monitor expected execution, not just errors.

This is where heartbeat monitoring helps.

The idea is simple:

A job sends a signal after it finishes successfully.
A monitoring system expects that signal within a known time window.
If the signal does not arrive, you get an alert.

This solves the "absence problem."

Instead of waiting for logs to be reviewed manually, or hoping the script emits a visible error, you treat a missing check-in as the failure signal.

Heartbeat monitoring is especially useful because it catches multiple failure modes at once:

cron daemon stopped
container never started
script crashed before completion
host rebooted and task did not come back
dependency failure prevented the final step
schedule changed and no longer runs as expected

It is one of the simplest ways to monitor scheduled jobs because it focuses on what actually matters: did the task happen on time?

For higher confidence, make the success heartbeat part of the normal execution path and configure a realistic grace period. That way you can catch both failed runs and jobs that simply stop reporting.

Simple solution (with example)

A simple pattern is to ping a monitoring endpoint after a successful run.

For example:

#!/usr/bin/env bash
set -euo pipefail

/usr/local/bin/generate-report

curl -fsS https://quietpulse.xyz/ping/YOUR_JOB_TOKEN

And in crontab:

0 * * * * /opt/jobs/hourly-report.sh

In this setup:

cron runs the script every hour
the script does its real work first
only after success does it send the heartbeat
if the heartbeat is missing, you know the job did not complete successfully in time

If you do not want to build this yourself, a lightweight heartbeat monitoring tool like QuietPulse can handle the expected schedule, missed-run detection, and alerting without much setup. The main point is not the brand, though. The important part is adopting a system that notices when a job does not report in.

Common mistakes

Here are the mistakes that cause the most pain in real systems.

1. Relying only on logs

Logs help after you know there is a problem. They are not enough to tell you a job stopped running entirely.

2. Discarding all output

Redirecting everything to /dev/null removes useful debugging signals and makes failures harder to investigate.

3. Monitoring the server, not the job

A healthy VM or container does not mean your scheduled tasks are healthy. Host uptime and job execution are different things.

4. Only alerting on explicit errors

Some of the worst failures produce no explicit error event. The job just never runs, or never finishes.

5. Not defining expected timing

You need a known schedule and some tolerance window. Without that, "missing" cannot be detected reliably.

6. Treating manual success as proof

A script that works when you run it manually is not proof that cron will run it correctly in production.

Alternative approaches

Heartbeat monitoring is usually the simplest option, but it is not the only one.

Log-based monitoring

You can ship logs to a central system and alert on known error patterns.

This works for jobs that fail loudly, but it misses cases where the job never starts or output is incomplete. It also tends to require more maintenance.

Exit-code wrappers

You can wrap tasks with a script that captures exit codes and sends alerts on non-zero status.

That helps for obvious failures, but still may not catch jobs that never launched at all.

Uptime monitoring

Traditional uptime tools are great for websites and APIs, but they are a poor fit for background execution. A working homepage tells you nothing about whether your nightly billing sync ran.

Queue and worker monitoring

For background workers and queue consumers, you can monitor queue depth, retry counts, and worker health.

That is useful, but cron-style jobs still need dedicated execution monitoring because they do not always map cleanly to worker metrics.

Build-your-own scheduler telemetry

Some teams store a "last successful run" timestamp in a database and alert if it gets too old.

This can work well, especially in larger systems, but it takes engineering time. For small apps and side projects, heartbeat monitoring is often faster and easier.

FAQ

Why do cron jobs fail silently so often?

Because cron itself only schedules command execution. It does not verify business success, and many failures happen in ways that produce no visible alert unless you monitor missing runs explicitly.

Are logs enough to monitor cron jobs?

Usually not. Logs are useful for diagnosis, but they are weak at detecting jobs that never started, never finished, or stopped running after an environment change.

What is the best way to detect missed cron runs?

A heartbeat-based approach is one of the best options. The job sends a signal when it succeeds, and you alert when that signal does not arrive on time.

Can uptime monitoring detect cron job failures?

Not reliably. Uptime checks can tell you whether a site or API is reachable, but they do not tell you whether scheduled background tasks are running correctly.

Should I monitor only job completion?

Completion is the most important signal because it confirms useful work happened. For many teams, that is enough. If you need more detail, combine heartbeat monitoring with local logs, metrics, or application-level tracing.

Conclusion

If you are wondering why cron jobs fail silently, the short answer is this: most systems are built to notice errors, not absence.

That is why scheduled tasks keep breaking in production without anyone knowing right away.

The fix is straightforward. Stop assuming cron execution equals success, and start monitoring expected job signals. Once you do that, missed runs become visible quickly, and silent failures stop being silent.

Originally published at https://quietpulse.xyz/blog/why-cron-jobs-fail-silently

Dead Man's Switch Monitoring for Scripts: Stop Silent Failures Before They Happen

quietpulse — Wed, 08 Apr 2026 06:17:15 +0000

Dead Man's Switch Monitoring for Scripts: Stop Silent Failures Before They Happen

Your cron job runs every hour. It usually finishes in 5 minutes. But what happens when it hangs, crashes silently, or gets stuck waiting for a resource? Traditional uptime monitoring won’t catch this — your server is up, but your script isn't making progress. That’s where dead man's switch monitoring comes in.

What Is a Dead Man's Switch?

A dead man's switch is a safety mechanism that triggers an action if a system stops sending signals. In monitoring, it means: if your script doesn’t report within an expected timeframe, raise an alert. It’s not about the server being down — it’s about your job being stuck.

Why Cron Jobs Fail Silently

Cron itself doesn't know if your script succeeded or failed; it just launches the process. Common silent failures:

Infinite loops or hangs due to external API timeouts
Resource exhaustion (memory, disk) that leaves the process alive but frozen
Unhandled exceptions that crash the script without notifying anyone
Dependency outages where the job waits indefinitely

Uptime checks (pinging port 80) won’t help here. You need to monitor execution health, not just server uptime.

How Dead Man’s Switch Works in Practice

Job heartbeat: Your script sends a ping to a monitoring endpoint at regular intervals during execution.
Expected window: You define a maximum allowed runtime (e.g., 10 minutes).
Missed deadline: If the monitor doesn’t receive a ping within that window, it triggers an alert.

It’s like a watchdog timer for your background tasks.

Implementing Dead Man’s Switch with QuietPulse

QuietPulse’s heartbeat monitoring is designed for this pattern:

Create a job with type=heartbeat.
Set interval to your script’s ping frequency (e.g., every 2 minutes).
Define grace period slightly longer than expected runtime (e.g., 12 minutes).
Integrate by adding a simple HTTP call to your script:

   curl -sS https://quietpulse.xyz/ping/YOUR-JOB-ID

Place it after every major step, or on a timer inside your script.

If your script hangs and stops pinging, QuietPulse will mark the job as “missed” and send a Telegram alert.

Benefits of Dead Man’s Switch Monitoring

Catches hangs and infinite loops that exit codes miss.
Works even when the server is up but your workload is stuck.
Minimal overhead — just a few HTTP requests per execution.
Platform-agnostic — works with any language or scheduler (cron, systemd timers, Kubernetes CronJobs, serverless functions).

FAQ

❓ What if my script sometimes runs longer than expected?

Set a generous grace period or use dynamic intervals — configure different ping intervals based on expected duration.

❓ Do I need to modify my script significantly?

No. One curl line at strategic points is enough. For long-running processes, you can run pinger in parallel.

❓ How is this different from regular cron monitoring?

Regular cron monitoring checks whether the job ran. Dead man’s switch checks whether it finished successfully. It detects stalls during execution, not just missing runs.

❓ Can I use QuietPulse’s dead man’s switch for non-cron tasks?

Absolutely. Any background process, queue worker, or scheduled task can send heartbeats.

Originally published at quietpulse.xyz/blog/dead-mans-switch-monitoring-scripts

How to Monitor Background Jobs in Production (and Stop Losing Data)

quietpulse — Tue, 07 Apr 2026 06:27:08 +0000

How to Monitor Background Jobs in Production (and Stop Losing Data)

Your Rails Sidekiq queue is growing. Your Celery workers are silent. Your Node.js job processor swallowed an exception at 3 AM and has been quietly dropping tasks ever since. Nobody noticed.

If you run background jobs in production — and you probably do — you already know the problem. Background jobs are invisible by design. They run outside the request/response cycle, behind a queue, often on a different server or process. When a web endpoint fails, the user sees an error. When a background job fails? Nothing happens. The job dies. And you find out three days later when a customer asks why they haven't received their confirmation email.

Learning how to monitor background jobs in production is one of those things that feels optional — until it isn't. This guide covers practical approaches to catching failed, stuck, and missing background workers before they cost you.

The Problem

Background jobs handle the stuff your users don't wait for. Sending emails. Generating reports. Processing payments. Syncing data with external APIs. You queue them up and they run when workers are available.

But queues and workers are fragile. Here's what can go wrong:

A worker process crashes and restarts without draining its queue
A job throws an unhandled exception and gets silently discarded
A third-party API changes and breaks your integration
A job retries forever, consuming resources but never completing
Your queue fills up because workers can't keep up
Someone deploys a change that breaks job serialization

And because most background job processors don't alert you by default, these failures accumulate silently.

Why It Happens

Background jobs run in a different execution model than HTTP requests. When a web request fails, the error bubbles up — the server returns a 500, logs it, and the user sees something is wrong. The feedback loop is instant.

Background jobs work differently:

A producer enqueues a job (usually as a serialized object or JSON payload)
A worker picks up the job from the queue
The worker processes it
If it succeeds, the job is marked complete
If it fails... well, that depends on your configuration

Here's the catch: many job processors have default retry logic that either retries forever (consuming resources) or gives up after N retries and discards the job without notifying anyone. No alert. No page. Nothing.

Additionally, background workers are daemon processes. They're meant to run continuously. If a worker dies (OOM, crash, bad deploy), you might not realize it until the queue backs up.

Why It's Dangerous

The danger of not monitoring your background workers is proportional to what those jobs do.

Payment processing fails. A Stripe webhook handler crashes. Three customers place orders. No invoices are generated. No emails are sent. You discover it when they email support.

Data sync breaks. Your job that syncs user data to your CRM fails on Monday. By Friday, your sales team is working with stale data. Deals get lost.

Batch operations silently drop. Your nightly data cleanup job stops working. Database grows. Query times increase. Eventually, the whole system slows down.

Notification pipeline dies. Password reset emails stop sending. Users think their accounts are broken. Support tickets spike.

The common pattern: background jobs handle critical operations, but without visibility, you only notice when something is already broken.

How to Detect Job Failures

There are three main signals you need to track when you want to monitor background jobs effectively:

Job success rate — how many jobs succeed vs. fail per time window
Queue depth — how many jobs are waiting to be processed
Worker health — are your worker processes even running

Job Success Rate: Heartbeat Monitoring

The simplest and most reliable approach is the heartbeat pattern: each successful job sends a signal to a monitoring endpoint. If the signal doesn't arrive within the expected window, something went wrong.

This is different from just reading logs. Heartbeat monitoring detects jobs that never started, workers that crashed, and queue backlogs — things that log-based monitoring misses entirely.

Queue Depth: Built-in Metrics

Most job processors expose queue metrics. Sidekiq has a web UI. Celery has Flower. BullMQ has a dashboard. These show you how many jobs are waiting, processing, and failed.

Queue depth alone won't catch everything (a worker can process bad jobs successfully), but it's a critical early warning signal.

Worker Health: Process Monitoring

Are your worker processes alive? Tools like systemd's ExecStart, supervisord, or Docker health checks can restart dead workers. But restarting is reactive — monitoring tells you why they're dying in the first place.

Simple Solution (with Example)

Here's a practical approach combining heartbeat monitoring with queue metrics.

Step 1: Add Heartbeat Pings to Your Jobs

The idea is simple: at the end of each critical job, send a heartbeat ping.

For a Bash script running as a cron-like job:

#!/bin/bash
# Background job: daily report generation

generate_report() {
    # ... your job logic ...
}

if generate_report; then
    curl -fsS --retry 3 https://quietpulse.xyz/ping/YOUR-JOB-ID > /dev/null
    echo "Report generated successfully"
else
    echo "Report generation failed" >&2
    exit 1
fi

For a Node.js worker:

const https = require('https');

async function processEmailJob(job) {
    await sendEmail(job.to, job.subject, job.body);

    // Send heartbeat on success
    https.get('https://quietpulse.xyz/ping/YOUR-JOB-ID');
}

For a Python Celery task:

import urllib.request
from celery import shared_task

@shared_task(bind=True, max_retries=3)
def sync_customer_data(self, customer_id):
    try:
        # ... sync logic ...
        pass
    except Exception as exc:
        raise self.retry(exc=exc, countdown=60)

    # Heartbeat on success
    urllib.request.urlopen('https://quietpulse.xyz/ping/YOUR-JOB-ID')

The key principle is the same across all languages: ping only on success, never on failure. A missing heartbeat tells you something went wrong.

Step 2: Monitor Queue Depth

If you're using Sidekiq, Celery, or BullMQ, set up a simple cron job that checks your queue size:

# Check Sidekiq queue size every 5 minutes
QUEUE_SIZE=$(redis-cli llen default)
if [ "$QUEUE_SIZE" -gt 1000 ]; then
    curl -fsS https://YOUR-ALERT-ENDPOINT/queue-backup
fi

Instead of building this yourself, you can use a heartbeat monitoring tool like QuietPulse to track job completion without maintaining additional infrastructure. Each monitored job gets a unique ping URL, and you get alerted via Telegram when jobs go missing.

Common Mistakes

Here are the most common mistakes teams make when trying to monitor background jobs:

1. Logging errors but never reading the logs. This is the most popular approach. It works great — right up until the first incident. Logs are passive. They don't wake you up at 3 AM.

2. Relying on retry logic as monitoring. Retries are a workaround, not a monitoring strategy. If a job keeps retrying, it consumes resources and delays the jobs behind it. You need to know when retries start, not after they've exhausted.

3. Monitoring queue size but not job success. A queue can be empty because all jobs succeeded — or because the workers crashed. Queue depth alone tells you nothing about job health.

4. Not tracking "zombie" jobs. A job that starts but hangs (waiting on a slow API, stuck in a deadlock) won't fail. It just... never completes. You need a timeout mechanism, not just a failure detector.

5. Using the same alert channel for all severity levels. If every retry, partial failure, and informational warning triggers the same email/Slack message, you'll develop alert fatigue. Critical failures need different channels than informational ones.

Alternative Approaches

Heartbeat monitoring is the simplest and most reliable approach, but here are other ways teams monitor their background jobs:

Dashboard-based monitoring. Sidekiq Web, Celery Flower, BullMQ Arena — these tools give you a visual overview of your queues. Great for day-to-day operations, but they require someone to be looking at them.

APM solutions. Datadog, New Relic, and Sentry offer background job monitoring as part of their broader platform. Powerful and comprehensive, but expensive and complex to set up.

Dead letter queues. When a job repeatedly fails, it's moved to a dead letter queue for manual inspection. Good for post-mortems, not great for prevention.

Custom middleware/wrappers. Some teams build custom wrappers around their job processor that log metrics and send alerts on every job execution. Flexible, but requires ongoing maintenance.

For most teams, a combination of heartbeat monitoring (for job success/failure) and queue monitoring (for capacity and worker health) covers the most ground with the least overhead.

FAQ

What's the difference between job monitoring and queue monitoring?

Job monitoring tracks individual job executions — did each job succeed or fail? Queue monitoring tracks the health of the queue itself — how many jobs are waiting, which workers are processing them, and is the queue backed up? Both are important, and you need both.

How do I monitor background jobs that run infrequently (weekly, monthly)?

For infrequent jobs, set your monitoring window to match the schedule. If a job runs weekly, expect one heartbeat per week with a grace period of a few hours to account for delays. The key is that you're monitoring for expected completions, not constant activity.

Should I monitor every background job or only critical ones?

Start with the jobs where a failure would have real consequences: payments, notifications, data syncs, backups. Less critical jobs (like analytics or cache warming) can be added later. Monitor what matters — the goal is signal, not noise.

Can I detect slow jobs, not just failed ones?

Yes. The heartbeat pattern catches slow jobs through the grace period mechanism. If a job usually completes in 30 seconds, set your monitoring window accordingly. If the heartbeat arrives late, you know the job is running slower than expected — even if it eventually succeeds.

Conclusion

Background jobs are essential infrastructure — but they're invisible by default. When they fail silently, the damage compounds over hours or days before anyone notices.

The fix doesn't require a full observability platform. Start simple: add heartbeat pings to your critical jobs, monitor queue depth, and set up alerting for when jobs go missing. Ten minutes of setup can save you from a three-day data recovery nightmare.

Your background jobs are doing critical work. It's time someone kept an eye on them.

This article was originally published on quietpulse.xyz

How to Get Alerts When a Cron Job Fails: Stop Silent Failures

quietpulse — Mon, 06 Apr 2026 06:28:58 +0000

How to Get Alerts When a Cron Job Fails: Stop Silent Failures

You wake up. Coffee. Check your phone. Nothing seems broken. But underneath, one of your nightly cron jobs — the one that syncs customer data, cleans up expired sessions, or sends out invoices — failed silently three days ago. Nobody noticed. No alerts fired. No panic. Just a slow, quiet accumulation of technical debt and angry users waiting to happen.

Getting cron job alerts when something goes wrong isn't just a nice-to-have. It's the difference between catching a bug at 2 AM with a quick fix and finding out at 2 PM on Monday when half your database is corrupted.

This guide walks you through why cron jobs fail silently, how to detect those failures in real time, and the simplest way to set up alerts that actually work. No fluff. No enterprise monitoring suites. Just practical steps you can implement today.

The Problem

Cron jobs are everywhere. Every developer has them. Backup scripts. Data processing pipelines. Email digests. Cache warmers. They run on a schedule, do their thing, and (hopefully) finish cleanly.

But here's the thing: cron itself doesn't care if your script fails. It fires off the command, waits for the process to exit, and moves on. If your script crashes with a non-zero exit code, cron doesn't retry. It doesn't send you an email. It doesn't page you. It just... stops.

The job might fail because:

A dependency updated and broke your script
The database was unreachable for 30 seconds
Disk space ran out
An API rate limit kicked in
The server restarted mid-execution

And because there's no built-in alerting, the failure goes unnoticed until someone manually checks logs or a downstream system breaks. By then, it's often too late.

Why It Happens

Cron is a scheduler, not a monitor. Its only job is to execute commands at specified intervals. That's it.

When you write 0 2 * * * /usr/local/bin/backup.sh, cron will:

Wake up at 2:00 AM
Execute backup.sh
Wait for it to finish
Log the exit code (if you've configured logging)
Go back to sleep

If backup.sh exits with code 1 (error), cron doesn't interpret that as "something went wrong, alert the human." It just records the exit and waits for the next scheduled run.

Most developers assume their cron jobs work because they usually work. They test once, deploy, and forget. Until one day, it doesn't work. And nobody knows.

Why It's Dangerous

Silent cron job failures create a false sense of security. Here's what actually happens when a critical job fails unnoticed:

Data loss. Your backup script failed last night. You don't find out until the server crashes three weeks later and there's nothing to restore from.

Stale data. Your data sync job hasn't run in five days. Your dashboard shows incorrect metrics. Your customers see wrong numbers. Your CEO asks questions you can't answer.

Cascading failures. One failed job blocks another. The cleanup script didn't run, so disk space fills up. Then the logging service crashes. Then the whole system goes down.

Revenue impact. Your invoicing job failed. Customers weren't billed. Churn goes up. Cash flow goes down. You find out during your monthly review.

The common thread? You didn't know until it was too late.

How to Detect It

The key insight is simple: instead of checking whether a cron job failed, check whether it succeeded.

This is the heartbeat pattern. Your cron job sends a signal (a "heartbeat") to a monitoring service when it completes successfully. If the monitoring service doesn't receive a heartbeat within the expected window, it knows something went wrong and alerts you.

Think of it like a dead man's switch. As long as the signal keeps coming, everything is fine. When the signal stops, someone gets notified.

This approach has several advantages:

It detects missing runs, not just failed ones. If cron itself crashes or the server goes down, you still get alerted.
It's simple. Your script only needs to make one HTTP request at the end.
It's language-agnostic. Bash, Python, Node.js, Ruby — doesn't matter. Just curl a URL.

Simple Solution (with Example)

Here's how you set up heartbeat monitoring for a cron job in under two minutes.

Let's say you have a backup script:

#!/bin/bash
# /usr/local/bin/backup.sh

pg_dump mydb > /backups/db-$(date +%F).sql
if [ $? -ne 0 ]; then
  echo "Backup failed" >&2
  exit 1
fi

echo "Backup complete"

Right now, if this fails, nothing happens. Let's add a heartbeat:

#!/bin/bash
# /usr/local/bin/backup.sh

pg_dump mydb > /backups/db-$(date +%F).sql
if [ $? -ne 0 ]; then
  echo "Backup failed" >&2
  exit 1
fi

# Send heartbeat
curl -fsS --retry 3 https://app.quietpulse.xyz/ping/YOUR-CRON-ID > /dev/null

echo "Backup complete"

That's it. The curl command sends a GET request to a monitoring endpoint. The flags mean:

-f: Fail silently on HTTP errors (non-2xx responses)
-s: Silent mode (no progress meter)
-S: Show errors even in silent mode
--retry 3: Retry up to 3 times if the request fails

Now, when the backup script completes successfully, it pings the monitoring service. If the service doesn't receive a ping within the expected time window (say, every 24 hours), it sends you an alert via email, Slack, Telegram, or webhook.

Setting up the monitor itself is straightforward. With a tool like QuietPulse, you create a monitor, give it a name ("Database Backup"), set the expected interval (daily), and configure your alert channels. The service gives you a unique ping URL. You drop that URL into your script. Done.

Instead of building this logic yourself, you can use a simple heartbeat monitoring tool like QuietPulse. It handles the ping tracking, alert routing, and escalation so you don't have to maintain another service.

Common Mistakes

Here are the most frequent mistakes developers make when setting up cron job monitoring:

1. Pinging at the start instead of the end. If you send the heartbeat before your job runs, a successful ping tells you nothing. The job could crash immediately after. Always ping after the critical work is done.

2. Not checking the exit code before pinging. Your script should only send the heartbeat if it actually succeeded. If you ping unconditionally, you're lying to your monitoring service.

3. Setting the timeout window too short. If your job usually takes 5 minutes, don't set the alert threshold to 6 minutes. Network hiccups, slow APIs, and database locks happen. Give yourself a buffer — 2x or 3x the normal runtime is a good starting point.

4. Ignoring flapping. If your job succeeds 90% of the time and fails 10%, you'll get constant alerts. Either fix the root cause or adjust your monitoring to alert on consecutive failures, not single misses.

5. Monitoring too many things with one endpoint. Each cron job should have its own unique ping URL. If you reuse the same endpoint for multiple jobs, you won't know which job failed.

Alternative Approaches

Heartbeat monitoring is the simplest and most reliable approach, but it's not the only one. Here are other ways people track cron job health:

Log parsing. Parse system logs (/var/log/syslog or /var/log/cron) for non-zero exit codes. Tools like logwatch or custom scripts can scan logs and send alerts. The downside? You have to manage log rotation, parsing logic, and alerting infrastructure yourself.

Email output. Cron can email you the output of every job by setting MAILTO=you@example.com in your crontab. This works for small setups, but it doesn't scale. You'll drown in emails, miss important ones, and have no way to track trends.

Uptime monitoring. Some teams wrap cron jobs in HTTP endpoints and monitor them with uptime checkers like UptimeRobot or Pingdom. This adds complexity (you need a web server) and doesn't distinguish between "job didn't run" and "job ran but failed."

Centralized logging. Send job output to a service like Datadog, ELK, or Papertrail. Set up alerts on error patterns. This is powerful but requires significant infrastructure and expertise.

For most developers and small teams, heartbeat monitoring strikes the best balance between simplicity and reliability.

FAQ

What's the difference between exit code monitoring and heartbeat monitoring?

Exit code monitoring checks whether a process returned 0 (success) or non-zero (failure). Heartbeat monitoring checks whether a signal was received within an expected time window. The key difference: heartbeat monitoring also catches cases where the job never ran at all (server down, cron crashed, job deleted). Exit code monitoring only works if the job actually started.

How often should I expect heartbeats?

This depends on your cron schedule. If a job runs daily, expect one heartbeat per day. If it runs every hour, expect 24 heartbeats. Set your monitoring service's grace period to account for normal variance — if a job usually takes 10 minutes, a 30-minute grace period gives room for occasional delays without false alarms.

Can I monitor cron jobs on servers without internet access?

If your server is completely offline, HTTP-based heartbeats won't work. In that case, you can use internal monitoring: write completion markers to a shared database, use a local message queue, or set up an internal webhook endpoint. The principle is the same — signal successful completion — but the transport mechanism changes.

Conclusion

Cron jobs will fail. It's not a matter of if, but when. The question is whether you'll find out before your users do.

Adding heartbeat monitoring to your critical cron jobs takes minutes and saves hours of debugging, data recovery, and apology emails. Ping when the job succeeds. Get alerted when it doesn't. That's the whole game.

Start with your most important jobs — backups, invoicing, data syncs. Add heartbeats. Configure alerts. Sleep better.

Originally published at quietpulse.xyz/blog/cron-job-alerts

Best Free Cron Monitoring Tools for Developers in 2026

quietpulse — Sun, 05 Apr 2026 06:22:56 +0000

Best Free Cron Monitoring Tools for Developers in 2026

If you've ever spent an hour debugging a data pipeline only to realize your cron job silently failed three days ago, you know the pain. Cron is powerful, but it's also "fire and forget." Without proper visibility, a silent failure can lead to missed backups, stale data, and unhappy users.

This is where free cron monitoring tools come in. They act as a safety net, alerting you the moment a scheduled task doesn't run as expected. In this guide, we'll walk through the best free options available to developers, indie hackers, and DevOps engineers who need reliability without the enterprise price tag. We'll look at what you actually get on these free tiers, where they fall short, and which one might be the right fit for your stack.

Why Free Monitoring Matters (And Why "It Worked on My Machine" Isn't Enough)

Most developers start with a simple crontab. It works for a while. Then you add a second job, then a third. Before you know it, you have a dozen scripts running at odd hours, and you have no idea if they're actually succeeding.

The problem with cron is its silence. By default, if a cron job fails, it might send an email to the local mail file on your server—a file you probably never check. If that email fails, or if the script hangs without an exit code, you're left in the dark.

Using a monitoring service flips this model. Instead of your cron job reporting to you, it checks in with the service. If the service doesn't hear from your job by a certain deadline, it assumes something went wrong and alerts you. It's a simple concept, but it's the difference between knowing about a failure in 5 minutes versus finding out when a customer complains.

For small projects and side hustles, paying $50 a month for monitoring isn't justifiable. That's why the "free forever" or generous free tiers of these free cron monitoring tools are so valuable. They give you professional-grade visibility for the cost of $0.

Quick Comparison: Free Tiers at a Glance

Before we dive into the details, here's how the top contenders stack up.

Tool	Free Limit	Alert Channels	Max Timeout (Free)	Credit Card Required?
Healthchecks.io	20 checks	Email, Slack, Telegram, Webhooks	1 day	No
Dead Man's Snitch	1 snitch	Email, Slack, PagerDuty	No limit	No
UptimeRobot	50 monitors	Email, Mobile App	N/A (Standard uptime)	No
Better Stack	10 monitors	Email, SMS (limited)	60 min	No
QuietPulse	5 jobs	Telegram only	24 hours	No

Healthchecks.io Free Tier — The Developer's Favorite

If you hang out in DevOps circles, you've probably heard of Healthchecks.io. It's widely considered the gold standard for open-source-friendly monitoring.

The Limits:
You get 20 checks for free. This is surprisingly generous. For an indie hacker, 20 checks can cover your entire infrastructure: database backups, data syncs, newsletter jobs, and cleanup scripts.

The Features:
What makes Healthchecks.io stand out is its flexibility. It supports a "push" model (your job sends a ping) and handles "grace periods" really well. If your job usually takes 10 minutes but sometimes hits 15, you won't get false alarms. It also provides a simple "ping URL" that you can curl at the end of your script.

# Example cron job
0 2 * * * /usr/bin/backup.sh && curl -fsS --retry 3 https://hc-ping.com/your-uuid-here

Best For:
Developers who want a set-it-and-forget-it solution with robust API support. The fact that you don't need to enter a credit card is a huge plus for privacy-conscious users. The free tier's 1-day maximum timeout is enough for almost all daily or weekly tasks.

Dead Man's Snitch Free Tier — One Snitch, But It's a Good One

Dead Man's Snitch (DMS) is a veteran in the space. It's known for its simplicity and reliability. However, the free tier is notoriously restrictive: you only get one snitch (monitor).

The Limits:
One job. That's it. If you want to monitor a second cron job, you need to upgrade.

The Features:
Despite the limit, DMS is incredibly polished. It has excellent integrations with Slack, PagerDuty, and email. It handles "expected runtimes" well, meaning it knows the difference between a 2-minute delay and a total failure. It also offers a "paused" state, which is handy when you're doing maintenance.

Best For:
Side projects with exactly one critical job. If you have a single backup script that must run every night, DMS is a solid, no-nonsense choice. But as soon as your project grows, you'll hit the wall.

UptimeRobot Free — 50 Monitors, But Is It for Cron?

UptimeRobot is primarily an uptime monitoring service (pinging your website to see if it's up). Its free tier offers 50 monitors, which sounds like a lot compared to Healthchecks.io's 20.

The Limits:
50 monitors, checked every 5 minutes on the free plan.

The Features:
Here's the catch: UptimeRobot isn't a true "cron monitor" in the push-model sense. It's designed to ping your server, not wait for your server to ping it. While you can configure it to monitor a "heartbeat" endpoint you build yourself, it lacks the native "I finished my job" logic of dedicated cron tools. You're essentially monitoring the uptime of an endpoint, not the success of a script.

Best For:
Developers who already use UptimeRobot for website monitoring and want to consolidate tools. If you're willing to build a small wrapper endpoint for your cron jobs, you can make it work. But for pure cron monitoring, it's a bit of a square peg in a round hole.

Better Stack Free — 10 Monitors and a Clean UI

Better Stack (formerly UptimeStatus) has made waves with its beautiful UI and modern approach to observability. Their free tier includes 10 monitors.

The Limits:
10 monitors, with checks every 3 minutes.

The Features:
Better Stack focuses heavily on incident management. When a cron job "fails" (doesn't ping), it creates an incident page, which can be useful for tracking historical reliability. It sends email alerts on the free tier, and the dashboard is arguably the best-looking in the industry.

Best For:
Teams or developers who value aesthetics and incident tracking. If you need to show a status page or track how often your jobs fail over time, Better Stack's free tier is a strong contender. However, it's less "developer-centric" in its setup compared to Healthchecks.io.

QuietPulse Free — Simple, Fast, and Telegram-Friendly

QuietPulse is a newer entrant that focuses on what many modern developers actually want: speed and direct communication. It's built for the "no-nonsense" crowd.

The Limits:
You get 5 jobs monitored for free.

The Features:
The standout feature here is the Telegram alerts. While most tools support Slack or Email, QuietPulse recognizes that many devs live in Telegram. Setting up a monitor takes seconds, and the dashboard is stripped of any bloat.

Perhaps most importantly, no credit card is required. You can sign up, add your 5 jobs, and start getting alerts immediately. It supports standard HTTP pings, making it easy to integrate with any existing script.

Best For:
Developers who want the fastest possible setup and prefer Telegram over email. The 5-job limit is perfect for small stacks or for monitoring your most critical "money-making" scripts. It's not trying to be an enterprise observability platform; it's trying to tell you your backup failed.

What "Free" Usually Costs — Limitations and Upgrade Pressure

When you sign up for these free cron monitoring tools, it's important to understand the "catch." In most cases, the catch is one of three things:

Alert Channels: Free tiers often restrict you to Email. If you want SMS, Slack, or PagerDuty, you're usually pushed to a $5–$20/month plan. QuietPulse is an exception here, offering Telegram on the free tier.
Retention: How long do they keep your logs? Free tiers might only keep 30 days of history. If you need to prove that a job ran consistently for a client audit, you might need to pay.
Frequency: Some tools limit how often you can check in. If you have a job that runs every minute, a tool with a 5-minute minimum check frequency (like UptimeRobot) won't catch a quick failure.

The "upgrade pressure" is real. Once you rely on these tools, turning them off feels risky. Providers know this. However, for most indie hackers, the free tiers are sustainable for a long time.

When to Upgrade from Free to Paid

You should consider upgrading when:

You exceed the monitor count: If you have 21 daily tasks, Healthchecks.io's free tier won't cut it.
You need "Start" and "Fail" pings: Some advanced workflows require pinging at the start and end of a long job to detect "zombie" processes that are still running but stuck.
You need On-Call Rotation: If you're part of a team, you'll need a tool that can route alerts to whoever is on duty.
SLA Requirements: If you're building a service for a client who demands 99.9% uptime proof, you'll likely need the historical data and reporting of a paid plan.

DIY Alternatives — Building Your Own

If you're truly on a budget (or just enjoy pain), you can build your own monitor.

The Basic Idea:

Set up a simple database (SQLite is fine).
Create an API endpoint that accepts a GET request.
Have your cron jobs curl that endpoint.
Write a separate "watchdog" cron job that runs every hour, checks the database for "old" pings, and sends you a message if something is missing.

Why You Probably Shouldn't:

Complexity: Now you have to monitor the monitor. If your DIY tool goes down, you're back to square one.
Maintenance: You're responsible for security, updates, and uptime of the monitoring service.
Time: Your time is worth more than $5 a month.

However, for learning purposes, building a basic heartbeat monitor is a great weekend project. Just don't expect it to be as reliable as a dedicated service like QuietPulse or Healthchecks.io.

FAQ

Q: Can I use these free cron monitoring tools for commercial projects?

A: Generally, yes. Most free tiers are for "personal" or "small business" use without a specific revenue cap, but always check the Terms of Service. Tools like Healthchecks.io are open-source, so you can even self-host them if you're worried about commercial restrictions.

Q: What happens if my cron job takes longer than expected?

A: This is where "grace periods" come in. Most of these tools allow you to set a window. For example, if a job runs daily, you can tell the tool to wait 24 hours plus a 1-hour grace period. If it doesn't hear from you in 25 hours, it alerts you. This prevents false positives for jobs that run a bit slow.

Q: Is it safe to put ping URLs in my crontab?

A: Yes, but with a caveat. The URL is essentially a "secret key." If someone else knows the URL, they can fake a successful ping. To mitigate this, use the "Retry" logic in your curl command (like --retry 3) to ensure the ping actually goes through, and consider using tools that support IP whitelisting if you're monitoring highly sensitive infrastructure.

Conclusion

Silent cron failures are a rite of passage for developers, but they don't have to be a recurring part of your workflow. By using free cron monitoring tools, you can add a layer of reliability to your infrastructure without spending a dime.

For most solo developers, Healthchecks.io's 20-check free tier or QuietPulse's Telegram-native approach will cover your needs. If you're monitoring just one critical job, Dead Man's Snitch is a solid choice. And if you already have UptimeRobot for website monitoring, you might be able to stretch it for cron jobs too.

The key is to start monitoring today. Pick one tool, add one heartbeat ping to your most critical job, and sleep better knowing you'll hear about failures immediately, not three days later when it's too late.

Originally published at quietpulse.xyz/blog/free-cron-monitoring-tools-for-developers

The Best Cron Monitoring Tools in 2026 — Honest Comparison

quietpulse — Sat, 04 Apr 2026 08:21:58 +0000

The Best Cron Monitoring Tools in 2026 — Honest Comparison

If your crontab grows past five entries and one of them silently fails at 3 AM, you already know why cron monitoring isn't optional. I learned this the hard way when a backup cron died for three weeks. Nobody noticed. Nobody got alerted. The backups simply stopped happening. That's the exact problem the best cron monitoring tools solve: they tell you when a scheduled job doesn't run, so you don't have to babysit logs or wait for users to complain.

This guide breaks down the most popular options — the good, the annoying, and the underrated — so you can pick something that fits your stack without overpaying.

Quick Comparison Table

Tool	Free Tier	Alert Channels	Pricing (from)	Self-hosted	Unique Angle
Healthchecks.io	20 checks, 100 pings/day	Email, Slack, webhooks, Telegram, PagerDuty	$20/mo	Yes (open source)	Simple, reliable, open-source core
Cronitor	5 monitors	Email, Slack, webhooks, SMS	$29/mo	No	Developer-friendly API, built-in logs
Dead Man's Snitch	1 snitch	Email, webhooks, PagerDuty, Slack	$29/mo	No	Minimalist, "I didn't hear from you" model
UptimeRobot	50 monitors	Email, Slack, webhooks	$7/mo	No	Uptime + heartbeat in one dashboard
Better Stack (Uptime)	10 monitors	Email, SMS, phone, Slack, webhooks	$29/mo	No	Beautiful UI, incident management
QuietPulse	5 jobs free	Telegram	$6.67/mo	No	Telegram-native, quarterly billing, crypto

Now let's look at each one in more detail.

Tool 1: Healthchecks.io

Healthchecks.io is probably the most well-known dedicated cron monitoring service. The concept is elegantly simple: each cron job gets a unique URL. Your script sends an HTTP GET (or POST) to that URL when it finishes. If Healthchecks.io doesn't hear from the URL within your configured grace period, it fires an alert.

Overview:

You set up a "check," grab the ping URL, and add something like curl -m 10 --retry 3 https://hc-ping.com/your-uuid to the end of your cron command. The check then tracks whether pings arrive on schedule, tracks execution time, and can even measure job success/failure via exit codes.

Healthchecks.io is also open source — you can self-host it if you prefer, which is a massive advantage for teams with strict data residency requirements.

Pros:

Dead simple to set up — one URL per job, done
Open source and self-hostable
Generous integration list: email, Slack, Telegram, webhooks, PagerDuty
Tracks job execution duration, not just "did it run"
API for managing checks programmatically

Cons:

Free tier caps at 20 checks and 100 pings/day — tight for production
No built-in log storage
UI is functional but dated
Basic escalation policies

Pricing:

Free: 20 checks, 100 pings/day
Standard: $20/month for 100 checks
Plus: Contact for larger deployments

Tool 2: Cronitor

Cronitor positions itself as the developer's cron monitoring tool. It goes beyond simple heartbeat monitoring by building in execution logs, runtime metrics, and a real-time dashboard.

Overview:

Cronitor provides libraries for many languages (Python, Node.js, Ruby, Go, PHP, Java, etc.) so you can wrap your jobs directly in code rather than appending curl commands to crontab entries. Each wrapped job automatically reports its status, runtime, and output to the Cronitor dashboard.

The tool also monitors cron schedules — meaning it can detect if your crontab itself was modified or corrupted, which is a surprisingly common failure mode in production.

Pros:

Native SDKs for major languages — cleaner than appending curl to every cron
Built-in execution logs
Schedule detection — warns you if crontab entries change unexpectedly
Good API for programmatic check management

Cons:

No free tier forever — trial only, then you pay
No self-hosted option
SDK adds a dependency you might not want
Pricing is on the higher side

Pricing:

Trial: 5 monitors, 14 days
Starter: $29/month for 50 monitors
Pro: $99/month for 500 monitors

Tool 3: Dead Man's Snitch

Dead Man's Snitch has a great name and a narrow focus: it expects to hear from you. If it doesn't, it sends an alert. That's the entire product philosophy.

Overview:

You create a "snitch" (their term for a heartbeat monitor), get a unique endpoint, and hit it from your cron job. The snitch expects a ping on your defined interval. No ping = alert. The dashboard shows snitch status, last ping time, and response time — nothing more.

Dead Man's Snitch also supports "tagging" snitches for organization, and their webhook integrations work well with PagerDuty and Slack. They've been around since 2013, which says something about their stability.

Pros:

Extremely simple — the simplest option on this list
No feature bloat
Reliable alerting with multiple channels
Good integration with PagerDuty and Opsgenie
Long track record — stable, battle-tested since 2013

Cons:

Free tier is limited to just 1 snitch
Minimal dashboard — great for simplicity, frustrating if you want details
No execution logs or output capture
No self-hosted option

Pricing:

Free: 1 snitch
Plus: $29/month for up to 200 snitches
Pro: $99/month for up to 2,500 snitches

Tool 4: UptimeRobot & Better Stack — Uptime vs Heartbeat

Uptime monitoring checks if your service is reachable. Heartbeat monitoring expects your job to call out. The former asks "is the server up?", the latter asks "did the job finish?"

UptimeRobot

UptimeRobot is primarily an uptime monitoring service that added heartbeat (cron) monitoring as a secondary feature. Their strength is monitoring public-facing endpoints — websites, APIs, ports — at high frequency.

Pros:

Excellent uptime monitoring — 50 free monitors, checked every 5 minutes
Very affordable — paid plans start at $7/month
Good multi-location checking
Public status pages included
Heartbeat monitoring available alongside uptime checks

Cons:

Heartbeat monitoring is a secondary feature, not the core product
Less granular cron-specific controls
API can be inconsistent between checks
Alert customization is basic

Pricing:

Free: 50 monitors (mix of HTTP, ping, and heartbeat)
Pro: $7/month
Pro+: Starting at $14/month

Better Stack (formerly Better Uptime)

Better Stack combines uptime monitoring with incident management and on-call scheduling. It's more of an incident response platform that happens to include heartbeat checks.

Pros:

Beautiful, modern UI — arguably the best-looking dashboard here
Full incident management with on-call scheduling
SMS, phone call, and email alerts
Status pages with good customization

Cons:

Overkill if you just need "tell me when a cron job fails"
More complex setup than a dedicated cron monitor
Pricing escalates quickly with team features
Free tier limited to 10 monitors

Pricing:

Free: 10 monitors, email only
Team: $29/month (billed annually)

The takeaway: if you already use these for uptime monitoring, heartbeat features might be "good enough." But for dedicated cron monitoring, a purpose-built tool gives more control.

Tool 5: QuietPulse

QuietPulse is a newer entrant that takes a different approach: minimal setup, Telegram-first alerts, and a pricing model designed for regions that traditional payment providers ignore.

Overview:

QuietPulse works on the same heartbeat model — each cron job gets a unique endpoint, you ping it when the job completes, and it alerts you when a ping is missed. The dashboard is clean and fast-loading, avoiding the feature bloat of larger competitors.

Where QuietPulse stands out is in its alert delivery. It's Telegram-first — alerts arrive as Telegram messages with near-instant delivery, message threading by monitor, and the convenience of responding to incidents from the app you probably already have open. This is especially popular with indie developers and small teams who live on messaging apps.

QuietPulse also accepts cryptocurrency payments, which matters if you're in regions like Belarus, Russia, or other areas where Stripe and PayPal are blocked. This isn't a gimmick — it's real accessibility for developers who can't sign up for Healthchecks.io or Cronitor even if they wanted to.

Pros:

Telegram-native alerts — fast, threaded, familiar
Simple, fast dashboard
Generous free tier for personal projects
Cryptocurrency payments — accessible worldwide
Lightweight — just HTTP pings, no SDK
Quick setup — get a monitor in under a minute

Cons:

Newer platform — less battle-tested time
Fewer third-party integrations — Telegram-only notifications (for now)
No built-in execution logs (yet)
Self-hosting is not available

Pricing:

FREE: 5 jobs, min interval 1 minute
STARTER: 20 jobs, min interval 1 minute — $20/quarter (~$6.67/mo)
UNLIMITED: ∞ jobs, min interval 1 minute — $50/quarter (~$16.67/mo)
Crypto payments available

How to Choose the Right Tool

1. How many cron jobs?

Under 20 jobs, want free? Healthchecks.io or QuietPulse. For 100+ jobs, paid plans are worth it — Healthchecks.io at $20/mo or QuietPulse STARTER at $7/mo.

2. What alert channels do you use?

Telegram → QuietPulse. Slack → any of these. PagerDuty/Opsgenie for on-call → Healthchecks.io, Cronitor, or Dead Man's Snitch.

3. Do you need self-hosting?

Only Healthchecks.io offers a self-hosted option (open source). If data residency matters, this is your choice.

4. Are you in a region without Stripe/PayPal?

Only QuietPulse accepts crypto. If you can't pay for competitors due to payment restrictions, this is the only dedicated option.

DIY vs Managed Solution

You could build your own heartbeat monitor in an afternoon: a simple API endpoint, a scheduler, and some alerting logic. But then you're maintaining another service — handling uptime, false positives, timezone edge cases, notification retries, and dashboard UI.

Managed tools cost $7-29/month. Your time debugging a home-built monitor at 2 AM costs a lot more.

FAQ

What's the difference between uptime monitoring and cron monitoring?

Uptime monitoring checks if your server is responding. Cron monitoring checks if your scheduled jobs actually ran. A server can be up while critical jobs fail silently.

Can I use these tools with non-cron scheduled tasks?

Yes. Any recurring task — GitHub Actions scheduled workflows, Kubernetes CronJobs, n8n flows, systemd timers — can send a heartbeat ping.

Is the free tier of Healthchecks.io or QuietPulse enough?

For personal projects and side hustles, yes. Both offer around 20 checks for free. Small teams might need a paid plan.

Conclusion

The best cron monitoring tool depends on your needs:

Most established? Healthchecks.io (open source, self-hostable)
Best developer experience? Cronitor (SDKs, logs, metrics)
Simplest? Dead Man's Snitch (one job, one snitch, done)
Already paying for uptime? UptimeRobot or Better Stack
Telegram alerts and crypto payments? QuietPulse ($7-25/mo, zero restrictions)

The common thread: set up heartbeat monitoring today, not after your backup silently dies for three weeks.

Heartbeat Monitoring for Cron Jobs Explained

quietpulse — Fri, 03 Apr 2026 07:21:14 +0000

Heartbeat Monitoring for Cron Jobs Explained

You set up a backup script to run every night at 2 AM. Cron says it's scheduled. The logs look fine from last week. But nobody actually checked whether it ran last night. Three weeks pass. A database corruption hits, and the backup that should have saved you — never ran. Nobody noticed.

This is the exact problem heartbeat monitoring for cron jobs solves: it tells you when a job doesn't show up on time, without you having to ask.

The Problem

Cron is fire-and-forget. You schedule a task, and that's it. If the job fails to start, hangs, or exits with an error code you don't capture — cron stays silent. There's no built-in mechanism to say "hey, I was supposed to run but something went wrong."

Most teams discover this the hard way. Reports stop generating. Backups go stale. Data syncs fall behind. And the alert comes from an angry customer, not from your own infrastructure.

Why It Happens

Cron jobs fail for reasons that have nothing to do with the script itself:

Resource exhaustion — the server ran out of memory, the process got killed by the OOM killer
Dependency failures — a database connection pool is full, an API endpoint moved
Silent hangs — a network request times out after your timeout threshold, or a lock file wasn't released from a previous run
Permission changes — a credentials file rotated, file permissions changed
Silent success — the script ran but produced corrupt output (exit code 0, wrong result)

None of these necessarily produce an error in the cron log. The system believes everything is fine.

Why It's Dangerous

The danger scales with how critical the job is. A daily report that stops generating is annoying. A nightly database backup that silently stops is catastrophic.

Here's what makes it worse:

It compounds — the longer a job has been failing, the harder it is to recover. Missing backups snowball. Unprocessed queues grow.
You lose trust — once you discover a silent failure, you start second-guessing everything else.
Detection costs time — by the time you notice, you're not fixing a 5-minute issue. You're recovering from weeks of accumulated damage.

The worst failures are the ones you don't know about.

How Heartbeat Monitoring Works

The concept is borrowed from network monitoring, where a "heartbeat" is a periodic signal that says "I'm alive." Applied to cron jobs, it works like this:

Your job sends a lightweight HTTP request ("I just finished") to a monitoring endpoint when it completes.
The monitoring system expects to receive this signal on a defined schedule.
If the signal doesn't arrive within the expected window, the monitoring system alerts you.

┌─────────────┐     ✅ "I ran!"      ┌──────────────┐
│  Cron Job   │ ──────────────────→   │  Monitoring  │
│  (any task) │                       │  Service     │
└─────────────┘                       └──────┬───────┘
                                             │
                                  Missed? ────┤
                                             │
                                       🔔 Alert!

The key insight: heartbeat monitoring detects absence of evidence. You don't need to predict every possible failure mode. If the job doesn't check in, something went wrong — and you get told about it.

Simple Solution with curl

The simplest way to add heartbeat monitoring to any cron job is a single curl command:

# Your actual job
/usr/local/bin/backup.sh

# Send a heartbeat signal (only if the previous command succeeded)
if [ $? -eq 0 ]; then
  curl -fsS -m 10 --retry 3 https://your-monitor-endpoint.com/beat/job-123
fi

This sends a GET request after the backup script completes successfully. The monitoring endpoint expects this request every 24 hours. If it doesn't arrive, it fires an alert.

For more detailed monitoring, send exit codes:

/usr/local/bin/backup.sh
EXIT_CODE=$?

curl -fsS -m 10 --retry 3 -X POST \
  -H "Content-Type: application/json" \
  -d "{\"status\": \"$EXIT_CODE\", \"duration\": \"$SECONDS\"}" \
  https://your-monitor-endpoint.com/beat/job-123

This pattern works with any cron job — shell scripts, Python scripts, Node.js, Go binaries. If your job can make an HTTP request, it can send a heartbeat.

Integrating QuietPulse into the Workflow

Instead of building this yourself, you can use a simple heartbeat monitoring tool like QuietPulse. You create jobs in the dashboard, copy a unique heartbeat URL into your scripts, and get Telegram alerts when jobs don't check in. No infrastructure, no configuration — paste a URL and you're done. You can try it at quietpulse.xyz.

Common Mistakes

1. Only Sending Heartbeats on Success

If your job fails and never sends a heartbeat, you'll get an alert — but you'll have no idea why it failed. Send the exit code or at least distinguish between "ran successfully" and "ran with errors."

2. Setting Timeout Windows Too Tight

If your job runs between 30 seconds and 3 minutes, don't set the monitoring window to 60 seconds. Random delays (slow DNS, temporary locks) will cause false alarms. Add buffer.

3. Not Handling the Heartbeat Request Itself

If the heartbeat HTTP call fails (network issue on your server), that shouldn't fail your job. Use curl -f with a timeout and don't chain it with set -e in bash scripts.

4. Monitoring Only the Easy Jobs

The jobs you monitor should be the ones that hurt most when they fail. Start with backups, data exports, payment reconciliation — not log rotation.

5. Ignoring the Alert

This sounds obvious, but it happens constantly: teams set up heartbeat monitoring, get the first alert, dismiss it as a fluke, and miss the real pattern. Treat the first missed heartbeat as a real failure until proven otherwise.

Alternative Approaches

Heartbeat monitoring isn't the only way to detect cron job failures, but it's often the most practical. Here's how it compares to other approaches:

Log Monitoring

Parse cron logs (/var/log/cron or journalctl) and look for execution entries. Pros: no code changes. Cons: doesn't detect hangs or silent errors. The job might run and produce garbage output.

Exit Code Tracking

Capture and store exit codes from every cron job execution. Pros: more detail. Cons: requires wrapping every job, and still doesn't detect jobs that never start.

Output Monitoring

Check that your job produces the expected output files or database records. Pros: validates actual results. Cons: complex to set up for every job, requires knowing the expected output format.

Uptime Monitoring

Traditional uptime checks (pinging a server, checking HTTP response). Pros: simple. Cons: only tells you the server is up, not that your specific jobs ran.

Heartbeat Monitoring

The job actively reports completion. Pros: detects any failure that prevents the heartbeat from being sent. Cons: requires a small code change (adding the HTTP call).

For most teams, heartbeat monitoring provides the best signal-to-noise ratio: simple to set up, reliable, and it catches exactly what matters — the jobs that didn't run.

FAQ

What is heartbeat monitoring for cron jobs?

Heartbeat monitoring is a pattern where a scheduled task sends a signal (like an HTTP request) when it completes. A monitoring system expects these signals on a defined schedule and alerts you if they stop arriving. It detects the absence of expected activity.

How is heartbeat monitoring different from log monitoring?

Log monitoring checks that cron tried to run a job. Heartbeat monitoring checks that the job actually completed successfully. A job can appear in cron logs while silently failing or hanging — heartbeat monitoring catches this.

Do I need a special tool for heartbeat monitoring?

Technically, no. You can build a basic version with a simple API endpoint. But dedicated tools like QuietPulse handle scheduling, alert routing, history, and edge cases (timezone handling, grace periods) out of the box.

How often should I expect heartbeats?

Your heartbeat interval should match your job's schedule plus some buffer. A daily job should heartbeat every 24 hours with a grace period of 1–2 hours. An hourly job might heartbeat every 60 minutes with a 15-minute grace period.

Can I send heartbeats from inside Docker containers or Kubernetes jobs?

Yes, as long as the container can make outbound HTTP requests. The heartbeat call is just a curl or equivalent — it works from any environment with network access.

Conclusion

Cron is great at starting jobs and terrible at telling you when they fail. Heartbeat monitoring closes that gap by having each job check in when it's done. One extra line in your script, and you'll never find out about a missed backup from an angry user again.

The simplest approach: add a curl call at the end of your critical jobs. If you want something that handles scheduling, history, and alerts without building infrastructure, tools like QuietPulse make it painless. Either way, monitor the jobs that matter.

Originally published at quietpulse.xyz/blog/heartbeat-monitoring-cron-jobs-explained

How to Detect if a Cron Job Is Not Running (Before It Becomes a Real Problem)

quietpulse — Thu, 02 Apr 2026 06:41:23 +0000

How to Detect if a Cron Job Is Not Running (Before It Becomes a Real Problem)

Your backup script was supposed to run every night. Your data import should have triggered at 6 AM. But nobody checked if they actually did. Here's how to catch a cron job not running before the damage is done.

The crontab entry is there. You set it up months ago, and since it didn't throw errors, you assumed it's been running fine ever since.

Three weeks later you realize your backups haven't been created since February. Your scheduled email digests stopped. Your database cleanup script expired.

A cron job not running is one of those problems that hides in plain sight. Unlike a server that crashes loudly, a silent cron just—doesn't happen. No error, no alert, no drama. Just a slow accumulation of missing data, unsent emails, and uncleaned state.

This article will show you exactly how to detect it and why heartbeat monitoring is the most reliable approach.

The Problem: Cron Jobs That Simply Don't Fire

Cron looks reliable on paper. You define a schedule, save it to crontab, and it "just works." But in production, things quietly break:

The server was rebooted, and the cron service never restarted
A package update changed the path to an executable
The cron daemon crashed under memory pressure
A deployment updated the script permissions
The machine image was replaced during a migration, and the crontab entry was lost

None of these generate error messages. Cron doesn't announce "I forgot to run this task." It just skips it.

If you're not actively checking, a cron job not running can go unnoticed for weeks or months.

Why This Happens

The core issue is fundamental: cron is fire-and-forget. It executes a command at a scheduled time and provides no built-in mechanism to confirm that the command actually ran—or succeeded.

There's no callback, no heartbeat, no "I ran at 3:00 AM as scheduled" signal. The only feedback is a local log file that nobody reads.

Consider this common crontab entry:

0 3 * * * /opt/scripts/backup-db.sh > /dev/null 2>&1

That > /dev/null 2>&1 part? It actively discards all output. Even error logs. You couldn't see a failure if you tried.

And even without output suppression, there's a difference between:

The cron daemon attempted to run the job (but the script failed instantly)
The cron daemon never triggered the job at all
The cron service itself stopped running

These are three different failure modes, and none of them alert you by default.

Why It's Dangerous

When a cron job not running goes undetected, the consequences compound over time:

Data loss: Database backups stop, and when you need to restore, the most recent backup is weeks old
Revenue impact: Scheduled billing or invoicing scripts don't fire—customers don't get charged
Security gaps: Certificate renewal scripts, security scans, and log rotation scripts stop working
User-facing failures: Automated emails, notifications, and reports stop without anyone noticing
Compliance violations: Audit log exports and data retention policies aren't enforced

The worst part? You won't find out during the failure. You'll find out during the crisis.

How to Detect a Cron Job Not Running

The most reliable way to detect a cron job not running is to use the heartbeat pattern—also known as a dead man's switch.

Here's how it works:

Your script "phones home" each time it runs by sending an HTTP request to a monitoring endpoint
The monitoring service expects to receive these signals on a schedule
If the signal doesn't arrive on time, the service alerts you

This gives you a simple but powerful guarantee: if you don't receive a heartbeat at the expected time, the cron job not running is confirmed—not presumed.

Basic Example: curl + Monitoring Endpoint

Here's the minimal implementation:

0 3 * * * /opt/scripts/backup-db.sh && curl -fsS --retry 3 https://monitor.yourdomain.com/heartbeat/abc123

Or, if you want to confirm the script ran regardless of success or failure:

0 3 * * * ( /opt/scripts/backup-db.sh; curl -fsS --retry 3 https://monitor.yourdomain.com/heartbeat/abc123 )

The monitoring endpoint receives a hit every time the job executes. If the expected heartbeat is late or missing, you get an alert.

A Simple Solution That Actually Works

You could build your own monitoring endpoint—a simple web app that records the last-seen timestamp per job and checks for stale entries. But there are easier options.

Using a Dedicated Heartbeat Monitoring Service

Tools like QuietPulse are built specifically for this. You create a job, get a unique heartbeat URL, and add a single curl command to your cron script.

Example script:

#!/bin/bash
# backup-db.sh

# Execute the actual task
pg_dump mydb > /backups/db-$(date +%Y%m%d).sql

# Send heartbeat confirmation
curl -fsS --retry 3 https://quietpulse.xyz/ping/your-unique-token

That's it. Two lines of monitoring for a cron job that could otherwise go silent forever.

With QuietPulse, you configure:

Minimum run interval (how often you expect the job)
Grace period (how long to wait before alerting)
Alert channel (Telegram notifications, for example)

When the job doesn't ping on time, you get notified before you even realize something's wrong.

Common Mistakes When Trying to Detect Cron Failures

Here are the traps people keep falling into:

1. Relying on exit codes alone

Exit codes tell you if the script failed—but they don't tell you if the script never ran. A cron job not running produces no exit code at all.

2. Checking log files manually

Manual log checks don't scale and depend on someone remembering to look. By definition, a process you "forgot about" won't have someone checking its logs.

3. Using uptime monitoring as a proxy

Uptime monitors check if your server is online. They can't verify if your specific scheduled task actually executed. Your server can be up for 99.9% and your cron can be failing 100%.

4. Alerting only on errors, not on silence

A missing event is fundamentally different from a failed event. You need a monitoring system that understands the difference between "the job ran and errored" and "the job didn't run at all."

5. Not testing the monitoring itself

If your monitoring endpoint goes down, you'll have a monitoring gap where a cron job not running is invisible. Test your monitoring setup periodically.

Alternative Approaches

Wrapper Scripts

Wrap every cron job in a shell script that logs start/end times and writes to a status file:

#!/bin/bash
echo "$(date) started" >> /var/log/backup.status
/opt/scripts/backup-db.sh
echo "$(date) completed" >> /var/log/backup.status

Then add a separate cron job that checks if the last entry is recent enough. This is essentially what a heartbeat service does, but built in-house.

Systemd Timers

Systemd timers can replace cron on Linux and provide better logging, restart policies, and dependency management. They won't eliminate silent failures, but they give you more observability.

Email Notifications from Cron

You can set MAILTO in crontab to receive emails on output. This helps with crashes but won't catch a cron job not running—the cron daemon must execute the job to generate any email.

FAQ

How do I know if my cron jobs are actually running?

The most reliable method is heartbeat monitoring: have each job send a signal (HTTP request, webhook) to a monitoring service when it executes. If the signal is missing at the expected time, you'll know immediately.

Can I detect a cron job not running without modifying the script?

Limited options exist. You can check system logs (/var/log/syslog or journalctl -u cron) for execution records, check if output files change, or use filesystem monitoring (inotify) on files the script modifies. But these are indirect and unreliable.

What's the difference between a cron job failing and not running?

A failed job started but encountered an error (non-zero exit code). A not-running job never started at all—cron didn't trigger it, or the cron daemon itself stopped. Heartbeat monitoring catches both.

How often should I check if my cron jobs ran?

Your check interval should be shorter than your job's run interval. If a job runs every hour, check within 15-30 minutes of the scheduled time. For daily jobs, check within a few hours.

What happens if the monitoring service itself goes down?

This is why some teams run redundant monitoring (e.g., both a SaaS tool and a local wrapper script). But in practice, monitoring services have higher uptime than individual servers—the real risk is a cron job not running, not the monitoring going down.

Conclusion

A cron job not running is the kind of failure that doesn't announce itself. The absence of activity is much harder to detect than a loud error. But it's also much more preventable.

A simple heartbeat ping after each execution—combined with a monitoring service that alerts you when the ping is late—gives you early warning that something's wrong, before the missing work becomes a real crisis.

Two lines of code. One monitoring endpoint. No more guessing.

Originally published at quietpulse.xyz/blog/how-to-detect-if-a-cron-job-is-not-running

Cron Job Failed Silently? Here's How to Detect It

quietpulse — Wed, 01 Apr 2026 11:12:04 +0000

You check the logs, nothing looks wrong. But the weekly report never ran. The cleanup job hasn't touched the database in weeks. Your cron job failed silently — and the system didn't breathe a word.

This is one of the more insidious backend reliability problems, because there's no exception to catch, no alert to acknowledge. Just a gap where something should have happened.

The Problem

Cron jobs are fire-and-forget. The scheduler fires the command and moves on. If the job crashes, exits with an error, or never starts at all — cron doesn't care. It doesn't have a built-in concept of "this was supposed to succeed."

The absence of an alert is not the same as a successful run.

Why It Happens

Exit codes are ignored — cron fires the command; it doesn't check the result.
Output goes nowhere — stderr and stdout typically go to a local mail queue no one reads.
Environment mismatches — cron runs with a stripped environment. No PATH, no .bashrc, no custom env vars. Scripts that work in your shell often fail silently under cron.
The server was down — if the machine reboots during the scheduled window, the job simply doesn't run.
Broken crontab — a syntax error silently disables every job on that machine.

Why It's Dangerous

The damage compounds with every missed cycle. A billing job that silently fails costs you money. A backup job that silently fails costs you data — you only find out when you need to restore. A sync job that stops running gives you stale data in production with no clean backfill path.

How to Detect It

Flip the model. Instead of alerting when something goes wrong (which requires you to know what went wrong), require the job to actively signal when it succeeds.

This is the heartbeat pattern: the job pings an external URL on successful completion. If the ping doesn't arrive on schedule, an alert fires. No ping = something is broken.

Simple Solution (With Example)

Add a single curl call at the end of your script:

#!/bin/bash

python /opt/scripts/sync_data.py

curl --silent --max-time 10 https://your-heartbeat-monitor/your-job-id

The curl fires only if the job gets there — meaning it ran to completion without crashing. If the script errors out early, the ping never fires.

For Python:

import requests
import sys

def run_sync():
    # your job logic
    pass

if __name__ == "__main__":
    try:
        run_sync()
        requests.get("https://your-heartbeat-monitor/your-job-id", timeout=5)
    except Exception as e:
        print(f"Failed: {e}", file=sys.stderr)
        sys.exit(1)

You can run your own endpoint to receive these pings, or use a dedicated heartbeat monitoring service that handles scheduling windows, alerting, and history for you.

Common Mistakes

Pinging at the start, not the end — you need proof of completion, not proof of launch.
Pinging on failure — if the ping fires regardless of exit code, it's useless.
No timeout on curl — a slow monitoring endpoint can block your job. Use --max-time 10.
Alert window too tight — if your job occasionally runs long, you'll get false positives. Buffer appropriately.
Trusting heartbeats alone — they confirm completion, not correctness. Validate outputs for critical jobs.

Alternative Approaches

Structured logs + alerting — ship JSON logs to Datadog or Loki, alert on missing entries. Requires log infrastructure in place.

Database timestamp checks — write last_run_at to a table, alert if stale. Couples monitoring to your app data.

Shell wrapper with email on failure:

#!/bin/bash
OUTPUT=$(python /opt/scripts/sync.py 2>&1)
if [ $? -ne 0 ]; then
  echo "$OUTPUT" | mail -s "Cron failed: sync.py" you@example.com
fi

Simple, but won't catch jobs that never started.

Native infra tools — Kubernetes CronJobs, Nomad, and some CI systems have job tracking built in. Use it if you're already there.

FAQ

What does "cron job failed silently" actually mean?
The job either didn't run or encountered an error, but nothing reported it. Default cron behavior produces no notifications, no logs in obvious places, and no failure state.

How do I confirm a cron job is running?
Short-term: redirect crontab output to a log file (>> /var/log/myjob.log 2>&1). Long-term: use heartbeat monitoring — a ping sent at the end of each successful run, with an alert if it doesn't arrive on time.

Uptime monitoring vs. cron job monitoring — what's the difference?
Uptime monitoring checks if a server or URL responds. Cron monitoring checks if a scheduled task completed. A server with perfect uptime can have silently failing jobs. Both matter; they solve different things.

Conclusion

Silent cron failures are invisible until they're expensive. The fix is simple: stop trusting silence, and require your jobs to prove they finished. One curl call, a heartbeat monitor, and you've closed the gap.

Start with your most critical jobs. Add the ping. Don't wait for a customer to tell you something broke.

Originally published at: https://quietpulse.xyz/blog/cron-job-failed-silently-how-to-detect-it

Cron Job Monitoring Best Practices (That Actually Prevent Silent Failures)

quietpulse — Tue, 31 Mar 2026 17:40:00 +0000

Cron jobs work great until they do not.

If you are looking into cron job monitoring best practices, it is probably because something failed quietly at some point.

Here is the core issue: cron gives you scheduling, not visibility.

The Problem

Cron jobs do not report their status.

You define something like:

0 * * * * /usr/local/bin/sync-data.sh

But you do not know:

If it ran
If it succeeded
If it failed halfway

Why It Happens

Cron is just a scheduler.

It does not:

Track execution results
Retry failures
Alert you

Also, cron runs in a minimal environment, which can break scripts in subtle ways.

Why It Is Dangerous

Backups silently fail
Data pipelines break
Business logic stops running

And you only notice later.

How to Detect It

Use heartbeat monitoring.

Your job sends a signal when it completes. If the signal is missing, something is wrong.

Simple Solution

Example

0 * * * * /usr/local/bin/sync-data.sh && curl -fsS https://example.com/heartbeat/sync-job

No request -> no success -> trigger alert.

Common Mistakes

Using ; instead of &&
Monitoring start instead of completion
No alerts configured
Ignoring stuck jobs
Relying only on logs

Alternative Approaches

Log monitoring (ELK, Loki)
Email via MAILTO
Uptime checks
Queue systems
Custom tracking

FAQ

What is the best way to monitor cron jobs?

Heartbeat signals plus alerting.

Can cron notify failures?

Not reliably.

Do I need external tools?

Usually yes, for proper monitoring.

Conclusion

Cron jobs are simple, but invisible.

Add a heartbeat and alert on missing signals. That is the simplest reliable setup.

Originally published at: https://quietpulse.xyz/blog/cron-job-monitoring-best-practices

DEV Community: quietpulse

Cron Job Not Running? A Practical Debug Guide for Production

The problem

Why it happens

1. The schedule is wrong

2. Cron runs in a different environment

3. The cron daemon is not active

4. Paths or permissions changed

5. Output is discarded

Why it's dangerous

How to detect it

Simple solution (with example)

Common mistakes

1. Debugging the script before confirming cron fired

2. Checking the wrong user's crontab

3. Assuming manual success proves cron success

4. Throwing output into /dev/null

5. Ignoring timezone configuration

6. Fixing it once without adding monitoring

Alternative approaches

System logs

Wrapper scripts with exit reporting

Framework schedulers

Heartbeat monitoring plus logs

FAQ

How do I debug a cron job that is not running?

Why does a cron job work manually but not automatically?

How do I know whether cron actually triggered a job?

What is the best long-term fix?

Conclusion

Common Cron Job Issues in Production and How to Prevent Them

The problem

Why it happens

1. Cron runs with a minimal environment

2. Dependencies change

3. Logging is not monitoring

4. Schedules are easy to misread

5. Jobs overlap

Why it's dangerous

How to detect it

Simple solution (with example)

Common mistakes

1. Relying only on logs

2. Monitoring only uptime

3. Not using absolute paths

4. Ignoring overlap

5. No alerting for absence

Alternative approaches

Logs

Exit code reporting

Queue-based schedulers

Uptime checks

FAQ

What are the most common cron job issues in production?

Why does a cron job work manually but fail in cron?

Are logs enough for cron monitoring?

How do I stop cron jobs from failing silently?

Conclusion

Why Cron Jobs Fail Silently (and How to Catch Them Early)

Why Cron Jobs Fail Silently (and How to Catch Them Early)

The problem

Why it happens

1. Cron has very little context

2. Output is easy to ignore

3. "Command started" is not the same as "job succeeded"

4. Many failures happen outside the script itself

5. No one notices missing execution

Why it's dangerous

How to detect it

Simple solution (with example)

Common mistakes

1. Relying only on logs

2. Discarding all output

3. Monitoring the server, not the job

4. Only alerting on explicit errors

5. Not defining expected timing

6. Treating manual success as proof

Alternative approaches

Log-based monitoring

Exit-code wrappers

4. Throwing output into `/dev/null`