Forem: Vincent Abolarin

Your Cron Job has Hung, but You May Never Realize It

Vincent Abolarin — Fri, 08 May 2026 12:25:31 +0000

A crashed cron job is easy to catch. It exits with a non-zero code. Your monitoring fires. You get an alert.

A hung cron job is different. It starts. It keeps running. It never crashes and never finishes. It holds a database connection, locks a file, consumes memory, and blocks every subsequent execution. Days later, you notice your data is three days stale and your server is running out of memory.

No alert fired. No exit code was ever logged. The job was "running" the entire time.

This is a hung job, and it's one of the most damaging failure modes in scheduled task infrastructure because it's entirely invisible to standard monitoring.

What causes cron jobs to hang

Hung jobs almost always trace back to one of five causes:

Database deadlocks or long-running queries. A query acquires a lock and waits for another lock that's held by a different process. Neither transaction can proceed. The job sits in a waiting state indefinitely, holding its own lock and blocking other operations.

Network timeouts without timeout configuration. An HTTP request to an external API, a message queue connection, a remote file transfer — if no timeout is explicitly set, the default in most runtimes is to wait indefinitely. A server that stops responding mid-response will leave your job waiting forever.

Infinite loops from unexpected input. A loop that processes records one by one, where a malformed record causes the loop to re-process the same item, or where a queue never empties because new items are added as fast as they're consumed.

Memory pressure causing extreme slowdown. A job that processes large datasets and runs out of heap memory doesn't always crash — it can enter a state of constant garbage collection where it's technically running but making no forward progress.

File system issues. A job that writes to a full disk, tries to acquire a file lock held by a crashed previous instance, or waits for input from a pipe that nothing is writing to.

Why standard cron job monitoring doesn't catch hung jobs

Standard heartbeat monitoring — where your job pings a URL when it completes — cannot detect hung jobs by design.

The ping only fires when the job finishes. A hung job never finishes, so the ping never fires. From the monitor's perspective, the job simply hasn't completed yet. It has no way to know whether the job is still actively working or has been frozen for six hours.

To detect hung jobs, you need two things:

A start ping — so the monitor knows when the job began
A maximum duration threshold — so the monitor knows when the job has been running too long

Only when both are present can an external service detect the difference between "job is still working" and "job has been stuck for four hours".

This is why Crontify uses a start/success/fail ping model rather than a single completion heartbeat.

How Crontify detects hung jobs

When your job calls start(), Crontify creates a run record with the current timestamp. The run is in a running state.

Every minute, Crontify's scheduler checks all runs in running state. For each one, it calculates:

seconds_running = now - startedAt
hung_threshold = monitor.gracePeriod * hung_job_timeout_multiplier

If seconds_running exceeds the threshold, the run is marked as hung and an alert fires. The default multiplier is 2 — so a monitor with a 30-minute grace period triggers a hung alert after 60 minutes of continuous running.

This detection is entirely external to your process. It fires even if your job is completely frozen, even if your process is consuming 100% CPU in a tight loop, even if the event loop is blocked.

Adding hung job detection to your cron jobs

Install the SDK:

npm install @crontify/sdk

The minimal instrumentation to enable hung job detection:

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

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

// wrap() calls start() at the beginning automatically
await monitor.wrap(async () => {
  await processLargeDataset();
});

That's it. The start() ping is sent when wrap() is called. If processLargeDataset() never resolves, Crontify detects the hung state after the threshold expires and sends an alert.

For manual control:

await monitor.start();

try {
  await processLargeDataset();
  await monitor.success({ meta: { records_processed: result.count } });
} catch (err) {
  await monitor.fail({ message: err.message, log: err.stack });
}
// If this code never reaches success() or fail(), 
// Crontify detects the hung state externally

Setting an appropriate maximum duration threshold

The hung job threshold is derived from the grace period you set for each monitor. Set it based on the longest reasonable runtime for your job — not the average.

A job that normally takes 5 minutes but can legitimately take 20 minutes under heavy load should have a grace period of at least 25–30 minutes. If it's still running after 50–60 minutes (2× the grace period), something is wrong.

Some rules of thumb:

Database backup jobs: 2–3× the average backup duration
API sync jobs: Set an explicit timeout on every HTTP request (e.g. 30 seconds), then set the monitor grace period to (number of records × 30 seconds) + buffer
Data processing jobs: Profile average runtime over 10 executions, set grace period to 2–3× the p95 duration
Email dispatch jobs: Usually fast (under 5 minutes); a 15-minute grace period is generous

Preventing hung jobs in the first place

Hung job detection tells you when it happens. These patterns reduce how often it happens:

Set explicit timeouts on all network calls:

// Never do this in a cron job
const response = await fetch(url);

// Always do this
const response = await fetch(url, {
  signal: AbortSignal.timeout(30_000), // 30 second timeout
});

Use database query timeouts:

// PostgreSQL statement timeout (per connection)
await prisma.$executeRaw`SET statement_timeout = '60s'`;

// Or per-query via raw SQL
await prisma.$queryRaw`
  SET LOCAL statement_timeout = '30000';
  SELECT * FROM large_table WHERE condition = true;
`;

Add a process-level timeout as a last resort:

// Kill the entire process if the job takes more than 10 minutes
// Only appropriate for jobs running in isolated processes
const TIMEOUT_MS = 10 * 60 * 1000;
const timeout = setTimeout(() => {
  console.error('Job exceeded maximum duration, exiting');
  process.exit(1);
}, TIMEOUT_MS);
timeout.unref(); // Don't prevent normal exit

try {
  await runJob();
} finally {
  clearTimeout(timeout);
}

Note that a process exit will trigger an error, which Crontify's SDK will catch and report as a failed run — which is correct and preferable to a hung run.

Frequently asked questions

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

A missed run never started — no start ping arrived within the grace period after the scheduled time. A hung job started but never finished — a start ping arrived, but no success or fail ping followed within the maximum duration threshold. Both require external monitoring to detect, but they represent different root causes.

Can a job be both hung and missed?

Yes, in sequence. If a job hangs indefinitely, it may still be technically "running" when the next scheduled execution is due. If the next instance detects the previous run is still active, it may refuse to start (depending on your configuration), resulting in what appears as a missed run. Crontify detects the hung state and fires an overlap alert if a new instance starts while the previous one hasn't finished.

How do I test that hung job detection is working?

Create a test monitor, instrument a test job that calls start() and then sleeps indefinitely (or just never calls success() or fail()). Within one detection cycle after your threshold expires, you should receive an alert.

// Test hung job detection — never call this in production
await monitor.start();
await new Promise(() => {}); // never resolves

Start monitoring for free

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

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

What Is AI, Really? A Plain-English Explanation

Vincent Abolarin — Mon, 13 Apr 2026 19:53:40 +0000

You’ve heard the word everywhere. On the news, in your workplace, from your kids. Artificial intelligence — AI — seems to be the answer to everything right now. But what actually is it? And do you need to care?

The honest answer: yes, you probably do. But it’s nowhere near as complicated as the tech world makes it sound. This guide cuts through all the jargon and tells you what AI actually is, what it can do for you right now, and how to start using it without a single line of code or a computer science degree.

Let’s Start With What AI Is Not

Before explaining what AI is, it helps to clear up what it isn’t — because most people’s mental image is completely wrong.

AI is not a robot that thinks like a human. It’s not HAL 9000 from 2001: A Space Odyssey. It doesn’t have feelings, motivations, or plans to take over the world. It’s also not magic, and it’s definitely not infallible.

AI is, at its core, a very powerful pattern-matching system. It has been trained on enormous amounts of text, images, code, and data — and it has learned to recognise patterns in all of that information well enough to generate useful responses to your questions.

Think of it like this: if you read every cookbook ever written, you’d get very good at suggesting recipes. You wouldn’t understand food the way a chef does, but you’d be remarkably useful in a kitchen. That’s roughly what modern AI does — at scale, and very fast.

So What Is “Generative AI” Exactly?

You’ll often hear the phrase generative AI used alongside names like ChatGPT, Claude, and Gemini. Generative AI refers specifically to AI that creates things — text, images, code, audio — rather than just analysing or sorting existing data.

When you type a question into ChatGPT or Claude and get a paragraph back, that’s generative AI at work. It has generated a response based on the patterns it learned during training. It hasn’t looked up your answer in a database the way Google does — it has essentially composed a response on the fly.

This is what makes it so flexible and, frankly, so impressive. You can ask it to write an email, summarise a document, explain a legal clause, plan a holiday, or debug a spreadsheet formula — and it will give you a coherent, useful answer each time.

The Main AI Tools You’ll Hear About

Right now, there are four names you’ll encounter most often:

ChatGPT (made by OpenAI) is the one that started the mainstream AI wave in late 2022. It’s the most widely used, holding around 60% of the AI chatbot market as of early 2026, and it’s a solid all-rounder. It handles writing, research, answering questions, and even generating images. Most people start here because it’s the name they’ve heard most.

Claude (made by Anthropic) has been quietly gaining ground. When you give it specific instructions — like “keep it under 200 words, conversational tone, no corporate jargon” — Claude actually follows them, which regular users quickly notice. It’s particularly strong for reading and analysing long documents.

Gemini (made by Google) is worth knowing about if you already live inside Google’s world — Gmail, Docs, Drive, Calendar. Its tight integration with Google services is its main selling point, meaning it can reach into your actual emails and documents rather than working in isolation.

Perplexity is worth paying attention to for everyday questions. Unlike the others, it searches the web in real time and shows you its sources — making it the most useful option when you need current, factual information you can verify.

All four have free tiers. You don’t need to pay anything to get started.

What Can AI Actually Do For a Normal Person?

Here’s where it gets practical. Forget the tech demos and the business case studies. For a regular person going about their day, AI can:

Save you time on writing. Drafting emails, writing a complaint letter, putting together a CV, composing a wedding speech — AI can produce a solid first draft in seconds that you then tweak into your own voice. You don’t have to stare at a blank page anymore.

Explain complicated things simply. Got a confusing insurance document? A legal letter you don’t understand? Paste it into ChatGPT or Claude and ask it to explain it like you’re twelve. It will.

Help you think things through. Planning a home renovation, deciding whether to switch jobs, trying to figure out a budget — AI is surprisingly good as a thinking partner. It won’t make decisions for you, but it will lay out considerations you might not have thought of.

Answer questions without a twenty-tab Google session. Instead of opening a dozen websites and piecing together an answer, you can ask AI a direct question and get a direct answer. For straightforward factual questions, this alone saves enormous amounts of time.

Handle repetitive tasks. Summarising meeting notes, formatting a list, turning bullet points into a paragraph — the small tedious jobs that eat your day are exactly what AI does fastest.

What AI Cannot Do (And This Matters)

Knowing the limits is just as important as knowing the capabilities — possibly more so.

AI makes things up. This is the most important thing to understand. When an AI doesn’t know something, it doesn’t say “I don’t know.” It generates a plausible-sounding answer anyway. This is called a hallucination, and it happens with all AI tools, even the best ones. Always verify important facts, especially anything medical, legal, or financial.

AI’s knowledge has a cut-off date. Most AI models were trained on data up to a certain point in time. Ask it about last week’s news and you may get an outdated or fabricated answer. Perplexity is the exception here, since it searches the web in real time.

AI doesn’t understand context the way humans do. It doesn’t know your situation, your history, or the nuance behind your question unless you tell it. The more context you give, the better the output.

AI is not a therapist, a doctor, or a lawyer. It can give you general information, but it cannot replace professional advice for anything serious.

Do You Need to Be Technical to Use It?

Not at all. If you can type a sentence, you can use AI. The interface for every major AI tool looks like a chat window — you type, it responds. There’s nothing to install for the basic versions, no account configuration required beyond signing up, and no commands to memorise.

The one skill worth developing is knowing how to ask good questions — what the AI world calls “prompting.” The better you describe what you want, the better the result you get. But even without any prompting knowledge, you’ll get useful output immediately. You can build up the skill gradually as you go.

Where Should You Start?

If you’ve never used an AI tool before, here’s the simplest possible starting point:

Go to claude.ai or chatgpt.com
Create a free account
Type something you’d normally Google — a question, a task, something you’ve been meaning to write
See what comes back

That’s it. You don’t need a plan, a course, or a tutorial. Just start a conversation.

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.