Skip to content
cronitorex.com
Cronitorex Cronitorex

Why Cronitorex

This content is not available in your language yet.

The problem

Your cron job died. You don’t know. The client emails in the morning: “why didn’t the report arrive?”.

Every dev/ops person running production systems has been there. A cron sits in crontab -e, runs for months, then quietly stops. Reasons:

  • exit code != 0, but stderr only goes to /dev/null
  • network glitch killed curl before it reached the external API
  • the database died overnight, restart killed the long-running ETL
  • someone committed a config change and the schedule flipped from 0 * * * * to 0 0 * * 0
  • expired SSL cert on an endpoint used by the script
  • any timeout, OOM, segfault

Every such outage is hours before anyone notices. Sometimes days, if the effect isn’t user-visible.

Common workarounds and their traps

“I’ll build my own monitoring.” And you’ll be writing alert rules all weekend. Plus maintaining a metrics stack. Plus deploying an agent on every host. Plus explaining a new query language to the next hire. Monitoring becomes a second product you have to keep alive.

“tail -f is enough, I’ll see it in the logs if something happens.” You won’t. Logs fail overnight and you read them in the morning when the client is already calling.

“There’s already a service that does this.” Sure, several. But: expensive at scale, no self-serve for PL/EU teams, pricing changes every year. Our API is straightforward, so moving over later is easy if you ever need to.

“Uptime Robot for uptime, healthchecks.io for crons.” Two tools, two logins, two pricings. Plus neither does SSL alerts and neither has a decent timeline dashboard.

What Cronitorex does

One product for three monitoring classes:

  1. Cron jobs / heartbeats. Send a run ping on start, complete or fail on end. Alert fires when the job doesn’t start on time, ran too long, or exited with code != 0.

  2. HTTP uptime checks. We ping your endpoints. Configurable interval, status code expectations, retry, threshold. Standard stuff.

  3. SSL certificate alerts. We check expiry dates once a day. We warn 30 / 14 / 7 / 1 days ahead.

Everything in one dashboard with an event timeline, CSV export, and a simple REST API.

Who it’s for

  • Solo dev / founder running a production system without an ops team.
  • Dev team with several dozen cron jobs across 3-12 servers, where nobody has time to build a full observability stack.
  • Agency running cron jobs for clients, multi-tenant via tags and separate notifications.
  • SRE / compliance needing 365 days of event history and an audit trail.

What’s next