Heartbeat intervals up to 30 days: monitor weekly and monthly cron jobs
Yesterday a user wrote to us in Telegram: they monitor cron jobs that run once a week and once a month, but the heartbeat form in the dashboard capped the expected interval at 24 hours. The API accepted longer intervals just fine — they had created their monitors through it — so the dashboard was simply lagging behind. Fair catch. Today it’s fixed.
What changed
Interval presets up to 30 days. The “Expected Check-in Interval” dropdown now offers 2 days, 3 days, 1 week, 2 weeks and 30 days on top of the existing minute-to-24-hour range — thirteen presets total. Weekly backups, biweekly reports, monthly billing exports: all of them can now be set up entirely from the UI.
Grace periods up to 24 hours. A job that runs once a month rarely lands on the exact second. The grace period — extra time we wait after the expected interval before alerting — now goes up to 24 hours (2, 6, 12 and 24-hour presets added), so a long-running batch job that drifts by a few hours won’t wake you up for nothing.
Honest uptime for long intervals. A subtle bug surfaced along the way: a perfectly healthy weekly monitor showed 0% uptime for the last 24 hours — because zero pings arrived in a window that was never supposed to contain one. Stats windows shorter than one expected interval now report “no data” instead of a false zero. The same fix landed in webhook check statistics, including event-driven checks with no expected cadence at all.
Why “30 days” and not “1 month”
The backend cap is exactly 30 days (2 592 000 seconds). A calendar month is sometimes 31 days, and 31 days is precisely the 30-day interval plus the maximum 24-hour grace — right on the deadline, where any delay would trigger a false alert. So the preset says what it means: 30 days. If your job runs “on the 1st of every month”, schedule the monitor for every 30 days and treat the occasional early ping as a bonus.
How to use it
Open Monitors → Create Monitor → Heartbeat, pick an interval — say, “1 week” — and a grace period that matches how much your job usually drifts. Point your cron job at the monitor’s ping URL:
0 3 * * 1 /usr/local/bin/weekly-backup.sh && curl -fsS https://pingzen.dev/api/v1/ping/YOUR_PING_KEY/YOUR_SLUGIf the ping doesn’t arrive within the interval plus grace, we alert you. If it does, you never think about it — which is the whole point.
Existing monitors created through the API now display their real interval in the edit form instead of a blank field.
Thanks to the user who reported this — feedback like that turns into shipped features fast. Found something off or missing? The feedback button in the dashboard’s bottom-right corner goes straight to us.