Cron & heartbeat monitoring
Get alerted when a cron job stops running — with the logs from the failed run
Heartbeats let LogBlazer actively monitor your services. Register a URL and LogBlazer pings it on a configurable schedule, parses a standardised JSON health response, and alerts you by email when checks fail. Results land in your project dashboard as monitor cards and log entries automatically — next to the output the job itself sent.
The debugging moment
Knowing the job failed is the easy half
A dedicated cron monitor tells you a job is late or missed. That is exactly what it promises to do, and it does it well. The problem is the next step: why did it fail? That answer lives in the job's output, which is usually in a different tool, behind a different login, with a different retention window.
With a cron monitor alone
- Check turns red at 3am.
- Alert fires — job missed its ping window.
- Open a second tab: your log tool.
- Search for the job name, filter by time range.
- Find the stack trace — or hit a per-job entry cap and see nothing.
With LogBlazer
- Check turns red at 3am.
- Alert fires — job missed its ping window.
- Click through to the same dashboard: the red heartbeat, the job's log output, and any metric monitor cards are all on one screen.
No tab-switching. No per-job log caps. One endpoint, one screen.
Two models
Push a ping, or let LogBlazer pull
Push: the dead-man's switch
Your job pings when it finishes. If the ping does not arrive inside its window, LogBlazer alerts you. Because a ping is one HTTP POST, the same crontab line that runs the job can send it — and it can carry the job's output as the payload, so the log and the health signal arrive together.
# nightly rollup — ping with the job's own output attached
0 3 * * * /srv/rollup.sh 2>&1 | curl -sX POST \
https://app.logblazer.com/api/logs/YOUR_API_KEY \
-H "Content-Type: application/json" \
--data-binary @- Pull: an active health check
Register a URL and LogBlazer pings it on a schedule, tracking health checks, response times, and alerting you when things break. Your endpoint responds to aGET carryingAccept: application/jsonwith an overall status plus individual checks — so one heartbeat can report on the database, the queue and the cache separately.
{
"status": "PASS",
"checks": {
"database": { "status": "PASS", "ms": 3 },
"queue": { "status": "WARN", "depth": 812 }
}
}Full field reference and the complete health check protocol are in theAPI documentation.
Coverage
Anything that should be alive on a schedule
Nightly batch jobs
Rollups, invoicing runs, report generation — the jobs nobody watches until finance asks.
Queue workers
A worker that dies quietly still drains no queue. A heartbeat catches the silence.
Webhook consumers
Stripe stops delivering and nothing errors, because nothing ran.
Backup scripts
The failure mode everyone discovers at exactly the wrong moment.
Replication and sync tasks
Drift is invisible until it is expensive. Ping on completion, alert on absence.
Scheduled cache warms
Silent expiry looks like a slow site, not a broken job.
FAQ
Cron monitoring questions
How does LogBlazer know a cron job stopped running?
Two ways, and you can use either. Your job can POST a heartbeat ping when it finishes, and LogBlazer alerts you when a ping does not arrive inside its expected window — the classic dead-man's-switch model. Or you register a URL and LogBlazer actively pings it on a configurable schedule, parsing a standardised JSON health response.
What makes this different from a dedicated cron monitor?
A dedicated cron monitor tells you the job is late or missed, and stops there. That is exactly what it promises and it does it well. The problem is the next step: why did it fail? With LogBlazer the red heartbeat, the job's log output, and any metric monitor cards are on the same screen, because the job shipped all three to the same endpoint.
Is there a cap on how much log output a job can send?
There is no per-job log cap. The free Hobby plan covers 500k lines/month across the project and Team covers 10M lines/month per user — you spend that budget however you like, on one chatty job or two hundred quiet ones.
What does the health check response need to look like?
For actively-pinged monitors, your endpoint responds to a GET carrying Accept: application/json with a JSON body containing an overall status and individual checks — for example {"status":"PASS","checks":{"database":{"status":"PASS","ms":3}}}. An Authorization: Bearer header can be attached if the endpoint needs one.
Can I monitor workers and queues, not just cron?
Yes. Anything that runs on a schedule or should be continuously alive fits the same model: nightly batch jobs, queue workers, webhook consumers, replication tasks, backup scripts. Register it as a heartbeat and LogBlazer tracks health checks, response times, and alerts you when it goes quiet.
Do I need a separate agent or daemon?
No. A heartbeat is one HTTP POST, so a cron entry can ping it with curl on the same line that runs the job. There is nothing to install, no port to open, and no firewall rule to file.
Wire up your first heartbeat tonight
Free forever plan, no credit card, heartbeat and monitor checks included. One curl line.