Cron Doctor · configuration analysis

systemd timer checker

Check OnCalendar, persistence, and service settings before trusting a timer. Then monitor whether the job actually checks in after completion.

No signup needed for the checker. Need ongoing monitoring? Pro covers up to 50 jobs for $9.99/month, for one owner.

Open Cron Doctor

What you can check

Review supported OnCalendar expressions and monotonic trigger context.
Inspect Persistent, AccuracySec, and RandomizedDelaySec settings.
Supply the matching service excerpt to review visible execution and timeout settings.

What remains unknown

The web checker does not supply host timezone context, resolve unit files or drop-ins, or observe your Linux host. Expect a partial report without exact future runs. Unsupported expressions and runtime-relative triggers remain explicitly limited; this is not full systemd unit validation.

Synthetic example

Combined excerpts from two separate unit files for analysis only. The timer and service are not one installable unit. Replace the synthetic command with your real workload; the checker does not verify that it exists.

# backup.timer excerpt
[Timer]
OnCalendar=*-*-* 02:00:00 UTC
Persistent=true
RandomizedDelaySec=2min

# backup.service excerpt
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-data
TimeoutStartSec=15min

Your configuration is sent to PingCron for analysis. It is not saved and is never executed. A static report does not establish runtime health.

Official scheduler reference · Explore ongoing monitoring

Check the timer on the Linux host too

Cron Doctor reviews the text you supply. Native systemd tools use your installed version and host context. For a daily 02:00 UTC calendar, inspect the expression locally:

systemd-analyze calendar --iterations=5 '*-*-* 02:00:00 UTC'
systemctl list-timers --all

Replace the expression with your actual OnCalendar value. For user timers, use systemctl --user list-timers --all. Calendar output describes nominal times; it does not include proof that the workload completed. Inspect the matching service and its journal locally before changing its configuration.

Persistent: a calendar timer can catch up with an activation after downtime; it does not replay every missed run or verify the output.
AccuracySec and RandomizedDelaySec: allow scheduling delay. Include that delay and normal workload duration when choosing monitoring grace.
An already-active service: a timer does not start a second instance of that same service. Check long runtimes and RemainAfterExit when expected runs appear missing.

References: systemd-analyze calendar · systemctl. Use documentation for your installed systemd version.

Keep systemd. Monitor 21–50 jobs for $9.99/month.

A configuration check ends when the report is generated. PingCron watches for completion check-ins outside your Linux host and alerts when an expected check-in is missing beyond its grace period. That can reveal a missed signal even when the host cannot send a local failure notification; it does not identify the cause or repair the job.

Pro covers up to 50 monitors for one account owner, with email, Slack, Discord, and webhook alerts. For 30 jobs and one user, published monthly prices are PingCron Pro $9.99, Healthchecks Business $20, and Cronitor Business $65. These are different feature bundles: Healthchecks offers 20 free jobs and shared projects; Cronitor Business offers 12-month retention and SMS/on-call features.

USD monthly list rates checked October 17, 2026; taxes, discounts, and add-ons excluded. Details and sources: Healthchecks cost and history comparison · Cronitor pricing comparison.

Pro retains 30 days of data for daily reported-outcome summaries. The individual list shows the latest 100 receipts, not a searchable month of application logs. Shared account access starts on Team; Pro alert destinations belong to the account owner.

Monitor one systemd job free Choose Pro — $9.99/month

Free: 5 monitors, 7-day history, no credit card. Pro: create your account, then continue to checkout.

Verify one real job before covering the rest

Create a monitor manually for a schedule PingCron can represent. Match its timezone and cadence; do not paste an OnCalendar expression into the cron field. Boot-relative or irregular timers may not fit a fixed calendar expectation.
Send a success check-in only after the service’s required work and output checks succeed. Timer activation, process startup, and a separate heartbeat timer do not prove completion. Preserve the workload’s exit status if reporting fails. See the completion-reporting shell example; adapt the wrapper under your service’s account and keep the existing systemd timer.
Inspect the real output, confirm a successful check-in from an automatic run, then verify your alert destination. Test missed-run and recovery behavior on an isolated monitor.