🇫🇷 SilenceWatch

Open-source heartbeat monitoring for cron jobs, workers and scheduled tasks. Your jobs check in when they run; when one goes quiet, you hear about it. Self-host it, or use the hosted service.

---

The problem

A scheduled job that silently stops running looks exactly like a scheduled job with nothing to do. No error is raised, no alert fires, nobody notices — sometimes for weeks. Backups, ETLs, exports and billing runs are the usual victims, and they are usually noticed by the person who needed yesterday's data.

SilenceWatch is a dead man's switch. Each monitored task sends a heartbeat (a plain HTTP call) when it runs. You declare how often it should run and how late it may be. If the heartbeat does not arrive in time, you get told.

# in a crontab
0 2 * * *  /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://app.silencewatch.com/p/<ping-key>

That is the entire integration for a shell script. For Java, Python and PHP, there is something better — see below.

Quick start: Spring Boot in five minutes

You have a Spring Boot application with @Scheduled methods or Quartz jobs. Nothing else is needed: no check to create, no URL to paste into a job.

1. Get a SilenceWatch. Create an account on the hosted service, app.silencewatch.com (there is a free plan), or self-host it with docker compose up -d.

2. Create an API key: Settings → API keys → New key. It is shown once; copy it.

3. Add the starter to your build, and the key to your configuration:

   <dependency>
     <groupId>com.silencewatch</groupId>
     <artifactId>silencewatch-spring-boot-starter</artifactId>
     <version>0.2.0</version>
   </dependency>
   

   silencewatch:
     api-key: ${SILENCEWATCH_API_KEY}
     # base-url: https://silencewatch.example.com   # only when you self-host
   

4. Start the application with SILENCEWATCH_API_KEY set. The log says SilenceWatch is watching 2 job(s), and each job is in Checks, tagged auto, with its real schedule. A heartbeat is sent around every run, with its duration and whether it failed.

5. Try it. Stop the application: the checks go late, then down. Add an alert channel (Alerting → New channel, then Send test) to be told.

It needs Java 17 or later, and scheduling switched on (@EnableScheduling, which your @Scheduled methods already need to run). It has been run against Spring Boot 3.5 and 4.1.

To see it without touching your own code, run the demo application: two scheduled jobs, one of which fails every third run.

What makes it different

Most monitoring tools ask you to create a check for every job and paste its ping URL into the job. SilenceWatch also ships client libraries that read your scheduler and do it for you: add the dependency and an API key, restart, and every scheduled job appears in SilenceWatch with its real schedule and sends a heartbeat around each run, with its duration and whether it failed. No check to create by hand, no ping URL to copy, nothing to keep in sync when the code changes.

Language	Package	Reads
Java	silencewatch-spring-boot-starter (Maven Central)	@Scheduled methods and Quartz jobs
Python	silencewatch (PyPI)	Celery beat, django-celery-beat and APScheduler
PHP	silencewatch/laravel (Packagist)	the Laravel 12 and 13 scheduler

All three work the same way:

1. At startup, one call declares every job found, with its real cron expression or interval. Each job has a stable identity, so its history survives restarts and deploys. A job that disappears from the code is flagged orphaned, never deleted.
2. Around each run, a heartbeat is sent: when it starts, then whether it succeeded or failed, with the duration.

And they follow the same rules, so they are safe to put in production: they never fail or block your job, they do nothing when there is no key or no network, and they bring no heavy dependency.

This is the beginning of the README. Read the rest at the original. Read the full README ↗