Most uptime monitoring focuses on binary states: Up or Down. Did the job run? Yes or no.

But any experienced backend engineer knows that performance degradation is often a far more insidious problem than a hard crash. If your nightly data aggregation script usually takes 30 seconds to run, and today it takes 45 minutes, it hasn't technically "failed" yet—but your infrastructure is screaming for help.

Why Duration Matters

Subtle increases in task duration are the canary in the coal mine for scaling issues. They often point to:

Missing database indexes that are scanning massive, newly created tables.
N+1 query problems that degrade linearly as your user base grows.
Third-party APIs rate-limiting you or responding sluggishly.

If you are only monitoring for binary "Down" states, you won't get an alert until the job takes so long that it overlaps with its next scheduled run, causing a massive deadlock and bringing your production systems to a halt.

The CronRabbit Start/Stop Signal

To combat this, CronRabbit doesn't just offer a single "I am done" ping. We offer a telemetry flow.

By pinging a dedicated /start endpoint at the beginning of your script, and a success endpoint at the end, our platform automatically tracks the execution duration over time.

# Signal job start
curl -fsS https://ping.cronrabbit.com/your-id/start

# ... Complex data processing ...

# Signal success, allowing CronRabbit to calculate exact duration
curl -fsS https://ping.cronrabbit.com/your-id/0

We chart these durations over time in your dashboard. If a script suddenly jumps from taking 1 minute to jumping to 20 minutes after a new deployment, you'll see the anomaly visually.

Start monitoring for speed, not just success, and catch architectural bottlenecks before they impact your users.