02:00 expected run
A billing export is expected at 02:00. The monitor already knows the real cadence and grace window.
Heartbeat monitoring for scheduled work
Know when a scheduled job did not run when it should have.
Cronic Watch helps teams running cron jobs, workers, imports, and syncs in production detect missed runs, understand the incident, and publish a factual update if that failure becomes customer-facing.
Primary job
Detect the missed run
Supporting job
Publish a factual external update if needed
Concrete example
What the product is built to catch
02:10 no heartbeat yet
No success heartbeat lands, so the check moves into the late window.
02:20 grace closes
The grace deadline passes, the incident becomes down, and the public page only matters if customers are affected.
Product
A focused product for scheduled jobs that fail by going silent.
Not an all-purpose observability suite, and not a standalone status-page product. The job is narrower: detect missed scheduled work, help the operator respond, and support outward communication only when needed.
Expected-run heartbeat monitoring
A scheduled job should have run by now, but the heartbeat did not land.
Operator context stays close to the signal
Schedules, grace windows, incident state, recent changes, and heartbeat history stay in one place.
The status page supports the monitor
The public page is for the smaller set of failures that become customer-facing.
What ships today
Grounded in the product that already exists.
Live surfaces in the current product, not roadmap filler.
Signed-in dashboard
Live surfaceCreate checks, set cron schedules and grace windows, and review status, pings, alerts, and incident context.
Route: /dashboard
Public status page
Live surfacePublish one public page per workspace with selected checks, overall health, recent updates, and incident history.
Route: /status/[slug]
Ping ingestion API
Live surfaceRecord start, success, and fail heartbeats so the monitor can compare actual runs with the expected schedule.
Route: POST /api/ping/[checkId]
API example
Heartbeat payload
POST /api/ping/[checkId]
{
"status": "success",
"duration": 842
}Accepts `start`, `success`, and `fail` heartbeats.
Current model
Current monitoring model
States: new, up, late, down.
Alerts: first-transition down email path.
Status page: publish selected checks or disable the page.
Strongest fit
For teams that already know which jobs matter.
Platform, reliability, and operations teams that own scheduled jobs in production.
Teams that need one place for expected runs, late windows, incidents, and public status.
Less relevant
Less relevant if you need something broader.
Pure request-response uptime monitoring with no scheduled heartbeat model.
Teams looking for a sprawling observability suite before they need a clear scheduled-job workflow.
Status pages
A public status page is included because some missed jobs become external incidents.
A supporting surface for the smaller set of scheduled-job failures that become external incidents.
It is there when a scheduled-job incident becomes a communication problem.
It publishes selected checks instead of dumping every internal monitor onto a public page.
It keeps outward updates tied to the monitoring workflow.
What readers get
Plain outward communication
Public route
/status/[slug]
One page for readers who need the current answer without signing in.
Current contents
Overall state, affected services, recent updates, and incident history.
Get started
Start with the scheduled job you least want to discover after the fact.
Create one monitor, wire one heartbeat, and confirm the first clean run. That is enough to tell whether Cronic Watch fits your workflow.