DEV Community: Vincent Abolarin

How to add cron job monitoring without changing your infrastructure

Vincent Abolarin — Sun, 12 Apr 2026 20:15:43 +0000

Most cron job monitoring advice involves significant infrastructure changes: configure a centralised logging stack, set up log forwarding, deploy a sidecar, integrate with your existing observability platform, write a custom alerting rule.

These are reasonable options for large teams with dedicated infrastructure engineers. For everyone else — a solo developer, a small team, a startup moving fast — the overhead of the setup is what prevents monitoring from happening at all. The result is production jobs running unmonitored for months until something visibly breaks.

There is a simpler model. Your jobs report their own status over HTTP. No new infrastructure. No log pipelines. No sidecar processes. Three HTTP calls per job run.

How the dead man's switch model works

Traditional monitoring is pull-based: a monitoring system checks whether something is alive. Dead man's switch monitoring is push-based: the thing being monitored announces its own health.

For cron jobs specifically:

Your job sends an HTTP POST to a monitoring endpoint when it starts.
Your job sends an HTTP POST when it completes successfully.
If no start ping arrives within the expected window, an alert fires. If a start ping arrives but no success ping follows within the maximum duration, an alert fires.

That's the entire model. The monitoring service holds the expected schedule and grace periods. Your job holds nothing except the API key and the monitor ID.

No changes to your cron infrastructure. Your jobs run wherever they already run — a VPS, a container, a serverless function, a Raspberry Pi. The monitoring is entirely external.

The integration is three lines

In Node.js with the @crontify/sdk package:

import { CrontifyMonitor } from '@crontify/sdk';

const monitor = new CrontifyMonitor({
  apiKey: process.env.CRONTIFY_API_KEY!,
  monitorId: 'your-monitor-id',
});

await monitor.wrap(async () => {
  await yourExistingJobFunction();
});

wrap() sends the start ping before calling your function, and the success or fail ping when it returns or throws. Your existing job function is unchanged.

For jobs that are not in Node.js, the same three pings are plain HTTP POST requests with an X-API-Key header:

# Start ping
curl -X POST https://api.crontify.com/api/v1/ping/your-monitor-id/start \
  -H "X-API-Key: ck_live_your_key"

# Your job runs here

# Success ping
curl -X POST https://api.crontify.com/api/v1/ping/your-monitor-id/success \
  -H "X-API-Key: ck_live_your_key"

In a shell script:

#!/bin/bash
set -e

MONITOR_ID="your-monitor-id"
API_KEY="${CRONTIFY_API_KEY}"
BASE_URL="https://api.crontify.com/api/v1/ping"

ping() {
  curl -fsS -X POST "${BASE_URL}/${MONITOR_ID}/${1}" \
    -H "X-API-Key: ${API_KEY}" > /dev/null 2>&1 || true
  # || true prevents monitoring failures from killing the job
}

ping start

# Your existing job logic
/usr/local/bin/your-backup-script.sh

ping success

In Python:

import os
import requests

def ping(event: str, monitor_id: str):
    try:
        requests.post(
            f"https://api.crontify.com/api/v1/ping/{monitor_id}/{event}",
            headers={"X-API-Key": os.environ["CRONTIFY_API_KEY"]},
            timeout=5,
        )
    except Exception:
        pass  # monitoring failure should never block the job

monitor_id = "your-monitor-id"

ping("start", monitor_id)
try:
    your_existing_job()
    ping("success", monitor_id)
except Exception as e:
    ping("fail", monitor_id)
    raise

What you get without touching your infrastructure

Missed run detection. Crontify parses your cron expression and knows when each run is expected. If no start ping arrives within your configured grace period, an alert fires. This catches missed runs caused by server reboots, cron daemon failures, and deleted crontabs — all situations where your existing logging would produce no evidence at all.

Hung job detection. If a start ping arrives but no success or fail ping follows within your maximum duration threshold, the run is marked as hung and an alert fires. This catches deadlocks, infinite loops, and network hangs that keep a process alive but not productive.

Run history. Every run is recorded with start time, end time, duration, and status. You get a dashboard showing run frequency, success rate, and duration trends over time.

Recovery alerts. When a monitor that was in a failing state receives a healthy ping, a recovery notification is sent automatically. You know when incidents are resolved, not just when they start.

Adding failure context without a logging pipeline

When a job fails, attaching the error context directly to the fail ping delivers it to your Slack or email alert without needing to configure log forwarding:

try {
  await runJob();
  await monitor.success();
} catch (err) {
  await monitor.fail({
    message: err.message,
    log: err.stack,  // up to 10,000 characters
  });
  throw err;
}

The first 500 characters appear inline in the Slack alert. The full log is stored in the run detail and accessible from the dashboard. This is not a replacement for a structured logging stack in large teams, but for a solo developer who doesn't have one, it means full failure context in the notification rather than a task to SSH into a server and find the log file.

The cost of not monitoring

The question is not whether monitoring is worth setting up. The question is whether the setup cost justifies it.

For infrastructure-heavy approaches, the answer is often no — until after the first incident that costs more than the setup would have. For the dead man's switch model with HTTP pings, the setup cost is under an hour for a first job. Once you have the pattern in one job, adding it to subsequent jobs is a few minutes each.

Crontify is free for up to 5 monitors — no credit card required.

How to add monitoring to gocron scheduled jobs in Go

Vincent Abolarin — Sat, 04 Apr 2026 15:39:49 +0000

gocron is the most widely used job scheduling library in Go. It handles the hard parts of scheduling — cron expressions, concurrency control, timezone awareness, singleton modes — and gets out of your way.

What it doesn't do is tell you when something goes wrong.

The gocron v2 documentation lists a Monitor interface and a MonitorStatus interface for collecting metrics from job execution. Both entries note the same thing: "There are currently no open source implementations of the Monitor interface available."

That gap is what this post addresses. Here's how to instrument your gocron jobs with external monitoring so you're alerted the moment a job fails, hangs indefinitely, or stops running on schedule.

What gocron monitoring gives you natively

gocron v2 exposes two scheduler-level monitoring hooks:

Monitor collects metrics per job execution. You implement the interface and attach it to the scheduler. gocron calls your implementation before and after each job run.

MonitorStatus extends Monitor with error and status tracking per execution.

Both are useful for local observability — feeding metrics into Prometheus, for example. But they don't solve the most important monitoring problems:

Missed runs: if gocron itself crashes or your process dies, nothing fires an alert because the scheduler is gone.
Hung jobs: gocron can detect that a job is taking longer than expected, but it doesn't alert anyone externally.
Silent failures: a job that completes without error but processes zero records looks identical to a successful run.

External monitoring solves all three. The approach: your jobs send start and completion pings to an external service. If a ping doesn't arrive when expected, you get alerted — even if your entire Go process is down.

The basic instrumentation pattern

For simple gocron jobs, add HTTP pings around the work:

package main

import (
    "context"
    "fmt"
    "log"
    "net/http"
    "time"

    "github.com/go-co-op/gocron/v2"
)

const (
    apiKey    = "ck_live_your_api_key"
    monitorID = "your-monitor-id"
    baseURL   = "https://api.crontify.com/api/v1/ping"
)

func ping(event string) {
    url := fmt.Sprintf("%s/%s/%s", baseURL, monitorID, event)
    req, err := http.NewRequest("POST", url, nil)
    if err != nil {
        log.Printf("ping %s: failed to build request: %v", event, err)
        return
    }
    req.Header.Set("X-API-Key", apiKey)

    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Do(req)
    if err != nil {
        log.Printf("ping %s: request failed: %v", event, err)
        return
    }
    defer resp.Body.Close()
}

func syncRecords() error {
    // your job logic
    return nil
}

func main() {
    s, err := gocron.NewScheduler()
    if err != nil {
        log.Fatal(err)
    }

    _, err = s.NewJob(
        gocron.CronJob("0 2 * * *", false),
        gocron.NewTask(func() {
            ping("start")

            if err := syncRecords(); err != nil {
                // Optionally POST error details to the fail endpoint
                ping("fail")
                log.Printf("syncRecords failed: %v", err)
                return
            }

            ping("success")
        }),
    )
    if err != nil {
        log.Fatal(err)
    }

    s.Start()
    select {}
}

This gives you missed run detection (if the start ping doesn't arrive within your grace period) and failed job detection (if fail is pinged instead of success).

Adding hung job detection

Hung job detection requires a start ping followed by a success or fail ping within a maximum duration. That's already provided by the pattern above — Crontify's scheduler checks for runs that started but never completed.

You can also add an application-level timeout using Go's context package to force-terminate jobs that run too long:

gocron.NewTask(func() {
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Minute)
    defer cancel()

    ping("start")

    done := make(chan error, 1)
    go func() {
        done <- syncRecords()
    }()

    select {
    case err := <-done:
        if err != nil {
            ping("fail")
            log.Printf("job failed: %v", err)
        } else {
            ping("success")
        }
    case <-ctx.Done():
        ping("fail")
        log.Printf("job exceeded 30 minute timeout")
    }
}),

If syncRecords() runs beyond 30 minutes, the context cancels, a fail ping is sent, and Crontify records the run as failed. The external hung job detection provides a second safety net — if your process itself hangs and never sends any ping, the monitor will alert after the threshold regardless.

Attaching metadata for silent failure detection

Go jobs often process records, sync data, or run aggregations. Attaching the count of what was actually processed lets you define alert rules on the output — firing an alert when a job succeeds but processes nothing.

The Crontify ping endpoints accept a JSON body on the success endpoint:

import (
    "bytes"
    "encoding/json"
)

type SuccessPayload struct {
    Meta map[string]any `json:"meta"`
}

func pingSuccess(meta map[string]any) {
    payload, _ := json.Marshal(SuccessPayload{Meta: meta})

    url := fmt.Sprintf("%s/%s/success", baseURL, monitorID)
    req, _ := http.NewRequest("POST", url, bytes.NewReader(payload))
    req.Header.Set("X-API-Key", apiKey)
    req.Header.Set("Content-Type", "application/json")

    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Do(req)
    if err != nil {
        log.Printf("pingSuccess failed: %v", err)
        return
    }
    defer resp.Body.Close()
}

// In your job:
result, err := syncRecords()
if err != nil {
    ping("fail")
    return
}

pingSuccess(map[string]any{
    "rows_synced":   result.Count,
    "duration_ms":   result.DurationMs,
    "errors_skipped": result.Errors,
})

In Crontify, you can then define a rule: rows_synced eq 0 → fire alert. The run is still logged as a success, but you get an immediate notification that something upstream is broken.

Wrapping it up as a reusable helper

If you have multiple gocron jobs to instrument, a small wrapper avoids repetition:

type CrontifyJob struct {
    MonitorID string
    APIKey    string
    BaseURL   string
}

func (c *CrontifyJob) Wrap(fn func() (map[string]any, error)) func() {
    return func() {
        c.ping("start")

        meta, err := fn()
        if err != nil {
            c.ping("fail")
            log.Printf("job %s failed: %v", c.MonitorID, err)
            return
        }

        if meta != nil {
            c.pingSuccess(meta)
        } else {
            c.ping("success")
        }
    }
}

Usage:

nightly := &CrontifyJob{
    MonitorID: "mon_abc123",
    APIKey:    os.Getenv("CRONTIFY_API_KEY"),
    BaseURL:   "https://api.crontify.com/api/v1/ping",
}

s.NewJob(
    gocron.CronJob("0 2 * * *", false),
    gocron.NewTask(nightly.Wrap(func() (map[string]any, error) {
        result, err := syncRecords()
        if err != nil {
            return nil, err
        }
        return map[string]any{"rows_synced": result.Count}, nil
    })),
)

What you get

After instrumenting your gocron jobs with external monitoring:

Missed runs alert you when a job doesn't start within its grace period — catches process crashes, server reboots, and OOM kills that take down the entire scheduler.
Hung jobs alert you when a job starts but never finishes — catches deadlocks, infinite loops, and database locks.
Silent failures alert you when a job completes but produces no output — catches empty upstream responses, failed database conditions, and zero-record syncs.
Recovery alerts fire automatically when a previously failing job returns to healthy.

Crontify is free for up to 5 monitors. No credit card required.

The cron job that always succeeded and never worked

Vincent Abolarin — Sat, 21 Mar 2026 23:44:19 +0000

Cron job monitoring usually answers one question: did the job run?

That's the wrong question.

Your job ran last night. Exited 0. No exceptions in the logs. Your uptime dashboard is green. And somewhere in your database, a table that should have 50,000 new rows from last night's sync has zero.

Not an error. Not a crash. A silence.

The job ran. It just didn't do anything. Maybe the upstream API returned an empty response. Maybe a config change stopped the data flowing. Maybe a schema migration broke a query in a way that returns zero rows instead of throwing. The job saw nothing wrong. So it reported nothing wrong.

You find out when a customer emails you.

This is a silent failure — and it is the hardest class of production failure to catch because the entire failure chain reports success. Your cron scheduler: success. Your job runner: success. Your cron job monitoring tool: success. Meanwhile your data is stale, your pipeline is broken, and nobody knows.

Why cron job monitoring misses silent failures

The standard model for cron job monitoring is heartbeat monitoring. Your job pings a URL when it runs. If the ping doesn't arrive within a grace period, you get an alert. Simple and effective for missed runs.

Some tools extend this to start/finish pings, which adds hung job detection — jobs that start but never complete. Valuable. But both approaches are still asking only one question: did the job execute?

Silent failures require asking a different question: did the job accomplish anything?

That requires data from inside the job. Data that only your code can provide. No external monitoring tool can know that your nightly sync processed zero records unless you tell it — which is exactly what Crontify's alert rules are designed for.

How to detect silent failures with alert rules

Crontify introduces alert rules on job output metadata.

When your job calls success(), you attach a metadata object describing what the run actually did:

import { CrontifyMonitor } from '@crontify/sdk';

const monitor = new CrontifyMonitor({
  apiKey: process.env.CRONTIFY_API_KEY!,
  monitorId: 'your-monitor-id',
});

await monitor.success({
  meta: {
    rows_processed: 0,
    records_synced: 0,
    api_calls_made: 14,
  }
});

You then define alert rules against that metadata in the dashboard:

rows_processed eq 0 → fire alert
records_synced lt 100 → fire alert
api_calls_made gt 1000 → fire alert

The run is logged as a success. Your historical success rate is untouched. But when a rule fires, Crontify sends an immediate alert to your configured channels — Slack, email, Discord, or webhook.

You can stack multiple rules per monitor and mix operators (eq, lt, gt, ne). This is silent failure detection built into the monitoring layer, where it belongs — not bolted onto your job's business logic.

The three failure types every cron job monitor should catch

Silent failures are the hardest to catch. The other three are the ones every developer knows they need:

Missed runs. Your job didn't start at all. Crontify parses your cron expression and knows when each run is expected. If no start ping arrives within your configured grace period, an alert fires. Works with any cron syntax including complex multi-part expressions and timezone-aware schedules.

Hung jobs. Your job started but hasn't finished within your threshold. Catches deadlocks, stuck database queries, and infinite loops that don't throw — the class of failure that keeps a process alive and doing nothing forever. Without start/finish pings, a standard heartbeat monitor can't distinguish "job finished in 2 seconds" from "job has been running for 6 hours".

Failed jobs. Your job explicitly called fail(), or the SDK caught an unhandled exception and reported it automatically.

Attaching log output to failed runs

When a cron job fails, you need context to diagnose it quickly. Crontify lets you attach the full log output directly to the failure ping:

try {
  await runJob();
  await monitor.success();
} catch (err) {
  await monitor.fail({ message: err.message, log: err.stack });
  throw err;
}

Up to 10,000 characters, stored separately and delivered directly in the Slack or email alert. No switching to your logging infrastructure at 2am. No searching through CloudWatch or Datadog to find what broke. The context is in the notification.

Instrumenting your jobs in under a minute

The SDK is zero-dependency TypeScript, published to npm as @crontify/sdk.

npm install @crontify/sdk

wrap() handles start, success, and fail pings automatically:

import { CrontifyMonitor } from '@crontify/sdk';

const monitor = new CrontifyMonitor({
  apiKey: process.env.CRONTIFY_API_KEY!,
  monitorId: 'your-monitor-id',
});

await monitor.wrap(async () => {
  const result = await syncDatabase();
  return {
    meta: {
      rows_processed: result.rowCount,
      duration_ms: result.durationMs,
    }
  };
});

If the function throws, fail() is called automatically with the error message. If it completes, success() is called with whatever metadata you return. If it never completes within your hung job threshold, the scheduler catches it on the next detection cycle.

If you manage multiple monitors in the same process, CrontifyClient caches instances by ID:

import { CrontifyClient } from '@crontify/sdk';

const crontify = new CrontifyClient({ apiKey: process.env.CRONTIFY_API_KEY! });

await crontify.monitor('mon_abc123').wrap(async () => { await syncUsers(); });
await crontify.monitor('mon_def456').wrap(async () => { await syncOrders(); });

Not using TypeScript? The ping endpoints are plain HTTP — /api/v1/ping/{id}/start, /success, /fail. Any language that can make an HTTP request works: Python, Go, Bash, PHP, Ruby.

Recovery alerts

Cron job monitoring isn't just about knowing when things break — it's about knowing when they're fixed.

When a monitor that was in a failing state receives a healthy ping, Crontify automatically sends a recovery notification to the same channels. You know when an incident starts. You know when it's over. You're not left refreshing the dashboard to find out if the fix worked.

Frequently asked questions

What is a silent failure in a cron job?

A silent failure is when a cron job completes without errors — exits 0, no exceptions — but fails to accomplish its intended purpose. For example, a sync job that processes zero records, an email job that sends to an empty list, or a cleanup job that deletes nothing because its filter condition is wrong. Standard monitoring treats these as successes because the job technically ran.

How do I monitor cron jobs in Node.js?

Install @crontify/sdk from npm, create a monitor in the Crontify dashboard, and wrap your job function with monitor.wrap(). The SDK handles start, success, and failure pings automatically. Full instrumentation takes under 60 seconds.

What is the difference between a missed run and a hung job?

A missed run means the job never started — no start ping arrived within the grace period after the scheduled time. A hung job means the job started but never finished — a start ping arrived, but no success or fail ping followed within the maximum duration threshold. Both require start/finish ping architecture to detect; a simple heartbeat monitor can only catch missed runs.

Does cron job monitoring work with languages other than JavaScript?

Yes. Any language that can make an HTTP POST request works with Crontify's ping API. The @crontify/sdk npm package is the easiest path for Node.js and TypeScript projects, but Python, Go, Ruby, PHP, Bash, and any other runtime can ping the three HTTP endpoints directly.

Start monitoring for free

Crontify is free to get started — 5 monitors, no credit card required.

crontify.com — SDK on npm as @crontify/sdk.

If silent failures are a gap in your monitoring, this is what Crontify was built to close.