Heartbeat monitoring: know when your scheduled jobs silently stop working

Source: Dev.to

Uptime monitoring tells you when your server goes down, but some of the worst outages look like this:

• The server is fine
• The cron scheduler fired
• Nothing visibly broke

The job just quietly stopped doing anything useful—a nightly data sync that hasn’t run in days, a backup that “completed” but wrote zero bytes, or a report job that started throwing exceptions weeks ago. These failures are invisible to a traditional HTTP monitor because the endpoint never fails.

Heartbeat monitoring solves this problem.

How it works

A heartbeat monitor is a dead‑man’s switch. Instead of Tickstem polling your endpoint, your job calls Tickstem at the end of every successful run. If the ping stops arriving within the expected interval + grace window, you get an alert.

You configure two things:

Alert rule: No ping for two consecutive intervals → alert sent.

Wiring it up

Go

import "github.com/tickstem/heartbeat"

client := heartbeat.New(os.Getenv("TICKSTEM_API_KEY"))

hb, err := client.Create(ctx, heartbeat.CreateParams{
    Name:         "nightly-sync",
    IntervalSecs: 86400,
    GraceSecs:    3600,
})

// at the end of every successful run — token is the credential, no API key needed
if err := client.Ping(ctx, hb.Token); err != nil {
    log.Println("heartbeat ping failed:", err) // non-fatal
}

Node.js

import { HeartbeatClient } from "@tickstem/heartbeat"

const hb = new HeartbeatClient(process.env.TICKSTEM_API_KEY)

const heartbeat = await hb.create({ name: "nightly-sync", interval_secs: 86400 })

// at the end of every successful run
await hb.ping(heartbeat.token).catch(err => console.error("ping failed:", err))

Curl (no SDK needed)

curl -s -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_TOKEN/ping

The token goes in the URL; no auth header is required. If curl fails, the script should still exit cleanly.

The thing worth noting

The ping only happens on success. Silence therefore means something went wrong—either the job crashed, was never scheduled, or completed without doing its actual work. Make the ping non‑fatal; a transient network blip shouldn’t abort a successful sync.

When to use it

Any job where “it ran” and “it did something useful” are different things:

• Database backups
• Data sync / ETL pipelines
• Report generation
• Invoice or payment processing
• Cache warming

Uptime monitoring and heartbeat monitoring are complementary:

• Uptime = server is alive.
• Heartbeat = job actually did its job.