Watchgoose is a heartbeat monitor for cron jobs, backups, and scheduled tasks. Your backup scripts, ETL jobs, sync routines, and maintenance tasks send a quick HTTP ping each time they complete successfully. If an expected ping doesn't arrive on time, Watchgoose alerts you - so a silently dead cron job doesn't go unnoticed for days.
Jobs can also report explicit failures and optional runtime state. There's no agent to install: anything that can make an HTTP request works.
Watchgoose is Europe hosted, operated & owned, supports Open Source projects.
Features
- Heartbeat monitoring — jobs ping on success; a missing ping after the schedule plus grace period triggers an alert
- Three schedule types — simple intervals, cron expressions, and systemd OnCalendar, each with a configurable grace period
- Explicit failure and runtime signals — /fail reports a known failure, /start optionally tracks that a job began
- 25+ notification integrations — email, Slack, Discord, Telegram, Microsoft Teams, Google Chat, Matrix, Mattermost, Rocket.Chat, Zulip, Signal, ntfy, Gotify, Pushover, Pushbullet, PagerDuty, Opsgenie, Splunk On-Call, PagerTree, Spike, GitHub, Trello, WhatsApp, and webhooks
- SMS and phone call alerts on paid plans
- Per-ping status and duration history, with plan-specific retention
- Projects and team access on paid plans, including read-only access for teammates or clients
- Project-scoped API supporting substantial check management, with read-only key support
- Embeddable SVG and JSON status badges for a single check, a tag, or a project summary
- No agent to install — works with anything that can make an HTTP request
- Europe hosted, operated & owned
- Free plan with 10 checks; 14-day trial of paid plans, no card required
Use Cases
- Backup jobs - know when a nightly database or file backup stops completing
- Cron jobs and systemd timers on servers you manage
- ETL, sync, and data pipeline jobs that run on a fixed schedule
- Maintenance scripts, certificate renewal, log rotation, cleanup routines
- Scheduled reports and billing runs that must go out on time
- Container and Kubernetes CronJobs, and scheduled CI/CD pipelines
- Agencies and MSPs tracking recurring jobs across multiple client projects, with read-only client access
- Dead man's switch for any recurring process that should check in regularly
Comments
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.
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?
Premium Products
Sponsors
Buy
Makers
Makers
Comments
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.
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?
Premium Products
New to Fazier?
Find your next favorite product or submit your own. Made by @FalakDigital.
Copyright ©2025. All Rights Reserved