Result-level monitoring for scheduled jobs

Your cron job ran.
The data is still wrong.

CronPulse checks the result of every scheduled job — not just whether it exited 0. Exit code 0 with 20 rows instead of 2,000? We catch it, explain it, and alert you before your users do.

one line at the end of any job
curl -X POST https://cron.ranlab.xyz/v1/ping/<token> -d '{"status":"ok","records":2041,"duration_ms":13420}'
Works with anything that can make an HTTP request: cron · bash · Node.js · Python · Go · Ruby · Java · GitHub Actions · Airflow

How it works

Three steps. No agent, no SDK.

1

Create a monitor

Get a unique ping URL from the dashboard. Set a schedule, a grace period, and the rules a good result must pass.

2

Ping at the end of the job

One HTTP POST with the facts: status, record count, duration, any result fields you care about.

3

Get alerted on bad results

Broken rules — or no ping at all — fire Slack and email alerts with the exact deviation, not a vague "job failed".

Result assertions

The part other monitors skip

Uptime checkers ask "did the process finish?" CronPulse asks "is the data actually right?"

status

Exit status

The job must report itself as ok — a green exit code means nothing here.

min_records

Minimum records

At least N rows synced. A "successful" run that touched 20 rows instead of 2,000 gets flagged.

max_duration

Duration ceiling

Slower than X ms is a regression. Catch the slowdown before it becomes a backlog.

fields_present

Required fields

Upstream changed their schema? Missing fields fail the run — silently renamed columns get caught.

field_value

Field values

A key metric must match expectations, e.g. state=success on every record.

baseline

History baseline

Records dropped 91% vs the p50 of your last runs? Flagged — with the deviation shown next to the history.

Why switch

Classic uptime monitor vs CronPulse

Uptime / exit-code monitorsCronPulse
Detects the job never ranYesYes
Detects exit code ≠ 0YesYes
Detects exit 0 but empty / partial dataNoYes — record assertions
Detects schema drift (missing fields)NoYes — field assertions
Detects silent volume drops vs historyNoYes — baseline (p05/p50/p95)
Explains what broke in the alert"Job failed""records=20, expected ≥ 1000"

Pricing

Pay for events, not monitors

Hobby
$0
10,000 events / month
  • Unlimited monitors
  • All 6 assertion types
  • Email + Slack alerts
  • 90-day history
Start free
Scale
Custom
Volume pricing
  • Everything in Growth
  • SSO
  • Custom retention
  • SLA
Talk to us

Quick start

From zero to first assertion in 3 commands

quickstart.sh
# 1. create a workspace + API key curl -X POST https://cron.ranlab.xyz/api/workspaces \ -H 'Content-Type: application/json' -d '{"name":"acme"}' # 2. create a monitor (save the returned token) curl -X POST https://cron.ranlab.xyz/api/monitors \ -H 'Authorization: Bearer <API_KEY>' -H 'Content-Type: application/json' \ -d '{"name":"nightly-sync","expect_min_records":1000,"period_minutes":1440,"grace_minutes":60}' # 3. at the end of your cron job curl -X POST https://cron.ranlab.xyz/v1/ping/<TOKEN> \ -H 'Content-Type: application/json' \ -d '{"status":"ok","records":2041,"duration_ms":13420}'

Stop finding out from your users.

Free forever for 10,000 events a month. Two minutes to set up.

Open Dashboard