Skip to content
cronitorex.com
Cronitorex Cronitorex
ENPL

Why Cronitorex

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 with Prometheus.” — and you’ll be writing alert rules all weekend. Plus maintaining a Grafana stack. Plus deploying node_exporters. Plus explaining to the new dev why PromQL has its own syntax.

“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 plays nicely if you ever want to migrate (see migration guide).

“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.

Who it’s NOT for

  • Real-time apps with per-second p50/p95/p99 latency metrics. That’s Prometheus / Datadog / New Relic. We don’t pretend to be a time-series DB.
  • Distributed tracing. That’s Jaeger / Tempo / Lightstep.
  • Application log aggregation. That’s Loki / ELK / Better Stack Logs.

Cronitorex does one thing: it watches that something started and finished as expected. That’s it. We don’t try to do the rest.

What’s next