Watchgoose

Love this — scheduled backups and cron jobs in one place, really convenient.

The heartbeat-ping model is nice and lightweight — no agent to install, just an HTTP call at the end of a job, so it works for pretty much any script or cron task regardless of language. Europe-hosted + open source support is a good detail for teams that care about where their monitoring data actually lives.

The grace period being configurable per schedule type is the detail that makes this usable. A nightly backup that normally finishes in four minutes and occasionally takes forty needs a different tolerance from a five-minute sync, and monitors that offer one global grace window end up either noisy or useless. Curious whether the /start signal lets you alert on a job that began and never finished, as distinct from one that never began, since those two failures usually need different people woken up.

With 25+ integrations, the operational edge case is alert fan-out during a regional outage. Can checks be grouped by dependency or muted through maintenance windows so one shared network failure creates a single incident instead of dozens of notifications?

Supporting systemd OnCalendar as a first-class schedule type is rare and genuinely useful — most monitors force you to translate it to cron and get it subtly wrong. How do cron checks behave across DST shifts: if a job runs at 02:30 local time and the clock skips that hour, does the grace logic count it as a miss or skip that day's expected ping?

Most of our infra is cron-shaped but we run one continuously-alive Node plus Socket.io matching service that isn't really a scheduled job -- it's more of a "ping every 30s or something's wrong" process. Does the simple-interval schedule type handle that kind of long-running heartbeat well, or is Watchgoose tuned specifically around jobs that start and finish?