A cron job can fail for months without anyone noticing. That gap between "it should be running" and "we know it stopped" is the whole reason Cronitorex exists.
Every backend team we talked to had the same story, just with different names attached. A nightly job that quietly stopped running three weeks ago. A certificate that expired over a long weekend. A queue worker that crashed on startup and nobody restarted it, because nothing told them it had died.
None of these are exotic failures. They are the most boring kind: a process that used to run, and then didn’t. The trouble is that “didn’t run” produces no stack trace, no error log, no 500 response. It produces silence, and silence looks exactly like success until someone goes looking for the output that never came.
Most monitoring tools are built to watch things that are up and answer a request. Point a check at a URL, get a response, compare it to what you expected. That model works well for a web server, and it works badly for a cron job, because a cron job has no URL to poll while it isn’t running. You cannot ask “did the 2 AM backup happen” from the outside. You can only find out by asking the job itself to tell you, at the moment it starts and at the moment it finishes.
That’s the whole idea behind a ping-based monitor: the job says run when it starts, and complete or fail when it ends. If neither of those ever arrives within the expected window, Cronitorex treats that silence as the alert. No polling, no guessing, no cron expression to reverse-engineer from the outside.
We also kept running into the same secondary problem: certificates. An HTTPS endpoint can pass every health check right up until the morning its certificate expires, at which point every client sees a broken padlock and nobody upstream had any warning. Uptime checks answer “is it responding,” not “will it still be trusted next week,” so we built certificate expiry into the same product instead of treating it as a separate tool to wire up.
We wanted the setup cost to be close to zero. No agent to install, no daemon to keep patched, no SDK to import. If your job can run a shell command, it can send a ping with curl, and that’s the entire integration:
curl "https://api.cronitorex.com/ping/nightly-backup?status=run"
pg_dump mydb > backup.sql && \
curl "https://api.cronitorex.com/ping/nightly-backup?status=complete" || \
curl "https://api.cronitorex.com/ping/nightly-backup?status=fail"We wanted alerts to say something useful in the first line: which monitor, what happened, and the exit code or response detail that tells you where to start looking, instead of a generic “something is wrong” that sends you hunting through five services.
And we wanted the whole thing to be affordable enough that a solo developer running a handful of cron jobs could use the free plan forever, not just during a trial. Thirty monitors, sixty second checks, no credit card. The paid plans exist for teams that need more history, more monitors, and channels like Slack and PagerDuty, not for gating basic reliability behind a paywall.
Cronitorex today watches three kinds of failure: missed or failed cron jobs, HTTP endpoints that stop answering the way they should, and certificates on their way to expiry. Alerts go out over email, Telegram, Discord, Slack, or a webhook to whatever you already use for on-call. Every account can publish a public status page, because “is it just me” is a question your users deserve an honest answer to.
If you have ever found out about an outage from a customer instead of from your own tooling, that’s the exact gap we built this to close.
Sign up, get an API key, paste the curl into your cron. That's it.