A cron job that dies quietly is worse than one that crashes loudly. Decode any cron expression below for free — then let DeskUptime keep watching the signals your jobs produce and alert you when they stop.
Check a cron expression See DeskUptime →Paste any five-field cron expression. You get a plain-English explanation of each field and the next scheduled run times in UTC — calculated locally in your browser.
Prefer the terminal? List what your crontab really runs:
# every user's scheduled jobs, in one view for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null && echo "↑ user: $u"; done # or let DeskUptime watch a job's output endpoint continuously: deskuptime watch https://example.com/jobs/status --interval 300
The five fields, what each accepts, and the mistakes people make with them.
| Field | Range | Common values |
|---|---|---|
| Minute | 0–59 | */15 every 15 min · 0 on the hour |
| Hour | 0–23 | 3 at 03:00 · */6 every 6 hours |
| Day of month | 1–31 | 1 first of month · * every day |
| Month | 1–12 | * every month · 1-6 Jan–Jun |
| Day of week | 0–7 (0 and 7 = Sunday) | 1-5 weekdays · 0 Sundays |
Watch out: when both day-of-month and day-of-week are restricted, most cron implementations run if either matches — not both. And @daily, @hourly etc. are aliases for fixed expressions, not extra features.
The schedule fires. Whether the work actually happened is a different question.
Cron emails output only when local mail works — on most servers it doesn't. A script that exits with an error writes to a log nobody opens, and everything looks green from the outside.
A backup moves from nightly to weekly, a server gets retired, a path changes in a deploy. The crontab keeps firing into the void — until the night you actually need the backup.
The worst way to learn a nightly import stopped running is a support ticket asking why data is stale. A monitor flips that: you get the alert, fix it, and nobody outside noticed.
Dedicated cron services use dead-man heartbeats that require modifying every job. There's a simpler route for anything that already produces an HTTP-visible signal:
| Your job already produces… | DeskUptime watches… | Alerts when… |
|---|---|---|
| A status/health endpoint | The URL on a short interval | It returns errors, times out, or slows down |
| A regenerated report or export page | The page's content hash | Content stops changing between checks |
| A public log or JSON artifact | The artifact URL + freshness | Status flips, or the file disappears |
| Nothing HTTP-visible yet | One line added to the job: curl -fsS https://yoursite/jobs/ping?job=backup | The ping endpoint stops refreshing |
Works the same whether the scheduler is Linux crontab, Kubernetes CronJob, GitHub Actions, systemd timer or a CI pipeline — a URL is a URL.
Telling apart "the schedule fired" from "the work happened". A watchdog notices when a job's visible signal — an endpoint, a regenerated page, a heartbeat ping — stops appearing, and notifies you within minutes instead of weeks.
Yes. Parsing and next-run calculation happen entirely in JavaScript in your browser. Nothing is sent to any server, nothing is logged, and there's no signup.
Because cron's own failure reporting depends on local mail delivery, which is unconfigured almost everywhere today. Combine that with scripts that don't exit non-zero on error, logs that rotate away, and paths that move during deploys, and a dead job looks exactly like a healthy one from the outside.
Add the URL(s) your jobs touch — a status endpoint, a report page, an artifact. DeskUptime re-checks them on your interval while your machine runs and sends a desktop notification or webhook alert when a check fails, responds too slowly, or its content stops changing. No account, no cloud dashboard, no subscription.
Yes. DeskUptime monitors URLs, not specific schedulers. Crontab, Kubernetes CronJobs, GitHub Actions, systemd timers, Windows Task Scheduler, Jenkins, GitLab CI — anything that leaves an HTTP-visible trace can be watched identically.
UTC, which is what most servers' clocks run on. If your crontab uses a different timezone (via CRON_TZ or a configured system zone), shift the preview accordingly — the field structure itself doesn't change.