Node.js Cron Monitoring

Know when your Node.js scheduled job stops running.

PingCron monitors Node.js scheduled tasks — node-cron, BullMQ repeatable jobs, Agenda, system cron, or pm2 cron_restart. One fetch() and you get alerted when the job stops checking in.

5 monitors free · No credit card · Live in under 60 seconds

Node-based schedulers fail differently than system cron.

When you schedule jobs inside a Node.js process — node-cron, Agenda, BullMQ repeatable jobs — the scheduler dies the moment the process dies. A crashed worker, a pm2 restart loop, an out-of-memory kill, or a Kubernetes pod eviction all mean every scheduled task in that process stops firing.

Even when the process stays up, jobs can fail silently. An unhandled promise rejection inside a node-cron callback doesn't crash the process — it just skips the work. A BullMQ repeatable job can stall if Redis disconnects and reconnects under the wrong conditions. An Agenda job's database lock can get stuck and block every subsequent run.

Node's eventloop won't tell you the work didn't happen. PingCron does.

Node scheduler failure modes:

  • pm2 silently crashed-and-restarted the process — node-cron timer reset
  • Unhandled promise rejection inside a node-cron callback was swallowed
  • BullMQ repeatable job stalled after a Redis reconnect
  • Agenda's MongoDB lock got stuck — jobs queue but never run
  • Kubernetes pod was evicted; new pod has no cron timer running yet
  • A deploy restarted the process at exactly the wrong second, missing a tick

Setup

One fetch() call inside your scheduled task.

Whether you use node-cron, BullMQ, Agenda, or system cron, the integration is one line.

Before

import cron from 'node-cron';

cron.schedule('0 * * * *', async () => {
  await syncOrders();
});

After

import cron from 'node-cron';

cron.schedule('0 * * * *', async () => {
  await syncOrders();
  await fetch('https://api.pingcron.io/ping/abc123');
});

Place the fetch call after the work completes. If the job throws before reaching it, no ping fires and PingCron alerts you after the grace period.

Real-world examples

node-cron with try/catch and fail ping

import cron from 'node-cron';

cron.schedule('*/5 * * * *', async () => {
  try {
    await processQueue();
    await fetch('https://api.pingcron.io/ping/abc123');
  } catch (err) {
    await fetch('https://api.pingcron.io/ping/abc123/fail');
    throw err;
  }
});

BullMQ repeatable job

import { Worker } from 'bullmq';

new Worker('reports', async (job) => {
  await generateReport(job.data);
  await fetch('https://api.pingcron.io/ping/abc123');
}, { connection });

Agenda job

agenda.define('nightly-cleanup', async (job) => {
  await purgeOldRecords();
  await fetch('https://api.pingcron.io/ping/abc123');
});

await agenda.every('0 2 * * *', 'nightly-cleanup');

System cron running a Node script

0 * * * * cd /app && node /app/jobs/sync.js && curl -fsS https://api.pingcron.io/ping/abc123

Node.js scheduling patterns we monitor.

In-process schedulers, distributed queues, and system cron-driven Node scripts.

node-cron jobs

In-process scheduler that ships with most Node apps.

BullMQ repeatable jobs

Redis-backed distributed queue with cron-style schedules.

Agenda jobs

MongoDB-backed scheduler popular with Express apps.

pm2 cron_restart

pm2 process configs that restart on a cron schedule.

System cron + Node

crontab calling node /path/to/script.js directly.

setInterval long loops

Persistent Node processes doing periodic work via setInterval.

Vercel Cron / Cloudflare

Serverless scheduled function invocations.

Docker containers

Node containers running scheduled work in K8s, ECS, Fly.

How it works

Works with every Node scheduling library.

01

Create a Node cron monitor

Pick the interval that matches your schedule (every minute, every 5 min, hourly, etc).

02

Add a fetch() at the end of the job body

Wrap the call in try/catch if you want to ping /fail on errors for instant alerts.

03

Deploy as you normally would

No infrastructure changes. The fetch is just an outbound HTTP request.

04

Get alerted on missed check-ins

Email, Slack, Discord, or webhook the moment a ping is overdue.

Alerts where you'll actually see them.

Configure as many channels as you want per monitor.

Email

HTML alerts with monitor details and direct links.

Slack

Post to any Slack channel via incoming webhook.

Discord

Native Discord webhook integration.

Custom webhooks

POST alerts to any endpoint with full payload.

FAQ

Inside the cron.schedule callback, call await fetch('https://api.pingcron.io/ping/<id>') after the work completes. If the job throws, the fetch never runs, and PingCron alerts you after the grace period. For instant failure alerts, wrap the body in try/catch and ping /fail in the catch block.
Yes. Inside the Worker's processor function, call fetch after job.data is processed. BullMQ handles retry semantics — PingCron tracks whether the scheduled work completed end-to-end. The two are complementary: BullMQ retries failed runs, PingCron tells you when no run is happening at all.
Yes. Inside the agenda.define() handler, call fetch after the work completes. Agenda's MongoDB locking continues to handle distribution; PingCron handles missed check-in detection.
Two patterns work. (1) Add a small Node script that pings PingCron and run it on the same cron schedule via pm2. (2) Have your main app ping PingCron on startup — pm2 cron_restart will trigger a fresh boot, which triggers a ping. The first option is more direct.
Yes. Both expose your scheduled function as a regular HTTP handler. Inside the handler, call fetch to ping PingCron after your work completes. Same pattern as any other Node scheduler.
BullMQ events tell you whether jobs in the queue are completing or failing — but only if the queue itself is alive and processing. PingCron tells you whether the scheduled job actually ran, regardless of whether your worker process is healthy. If your BullMQ worker crashed and no one knows, BullMQ events are silent. PingCron isn't.
Yes. 5 monitors free with email, Slack, and Discord alerts. No credit card required.

Related monitoring guides

Catch silent Node scheduler failures before customers do.

One fetch() inside your job. Get alerted the moment a check-in is missed.

Start monitoring free

5 monitors free · No credit card · Live in under 60 seconds