Cron jobs and uptime monitoring belong together

May 2, 2026 · 5 min read

When a scheduled job fails, the first question is always the same: is the scheduler broken, or is the endpoint down? Without uptime monitoring, you spend the first five minutes of every incident answering that question manually — curling the URL, checking logs, asking teammates.

That's why we built uptime monitoring into Tickstem alongside cron scheduling. One dashboard, one API key, one alert when something goes wrong — and you already know which half of the system is responsible.

How it works

You register a monitor with a URL and a check interval. Tickstem sends an HTTP GET to that URL on the interval you specify — every 60 seconds on Starter, every 30 seconds on Pro and Business. If the endpoint returns a 2xx or 3xx, the check is recorded as up. Anything else — 4xx, 5xx, connection timeout, DNS failure — is recorded as down.

After two consecutive failures, the monitor flips to failing status and sends you an email. When it recovers, you get a recovery notification. Simple, no configuration beyond an email address.

Setting up a monitor

From the dashboard, click Monitors → New monitor. Or via the API:

curl -X POST https://api.tickstem.dev/v1/monitors \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production API",
    "url": "https://api.yourapp.com/health",
    "interval_secs": 60,
    "timeout_secs": 10
  }'

Or with the Node.js SDK:

import { UptimeClient } from "@tickstem/uptime"

const uptime = new UptimeClient(process.env.TICKSTEM_API_KEY)

const monitor = await uptime.create({
  name: "Production API",
  url: "https://api.yourapp.com/health",
  interval_secs: 60,
})

console.log(monitor.id) // use this to query checks later

Checking recent results

const checks = await uptime.checks(monitor.id)

for (const check of checks) {
  console.log(check.status, check.duration_ms + "ms", check.checked_at)
}

Each check records the HTTP status code, response time in milliseconds, and any error message. The full history is available in the dashboard or via GET /v1/monitors/{id}/checks.

The cron + uptime connection

The real value isn't having uptime monitoring — it's having it in the same place as your cron jobs. Consider the common failure scenario:

Your daily report job fires at 06:00
The job is marked as failed in the execution history
You get a failure alert from Tickstem

Without uptime monitoring, you open your logs, try to figure out if the scheduler reached your endpoint, check if the server was down. With a monitor on the same endpoint, you open Tickstem and see immediately: the monitor was already failing at 05:58. The server was down. The cron scheduler did its job — the endpoint didn't.

A good rule of thumb: every endpoint your cron jobs call should have a monitor. Not because something will definitely go wrong, but because when it does, you want the answer in the same place as the alert.

Plan limits

The Free plan supports up to 5 monitors with a minimum 5-minute check interval. Starter gets 20 monitors at 1-minute intervals. Pro and Business get 100+ monitors at 30-second intervals. All plans send email alerts with no extra configuration.

Uptime monitoring is available now in the Tickstem dashboard. The API and SDKs are live — Go SDK coming soon.