Spring Boot monitoring: @Scheduled and Quartz
In a Spring Boot application, scheduled tasks multiply and nobody keeps the list up to date. The SilenceWatch starter keeps it for you: it discovers every @Scheduled method and every Quartz job, declares them with their real schedule, and reports every run.
One dependency, one key
Section titled “One dependency, one key”<dependency> <groupId>com.silencewatch</groupId> <artifactId>silencewatch-spring-boot-starter</artifactId> <version>0.1.0</version></dependency>silencewatch: api-key: ${SILENCEWATCH_API_KEY}Restart the application. Every @Scheduled method and every Quartz job appears in SilenceWatch with its real schedule, and sends a heartbeat around every run, with its duration and any exception. No check to create by hand, no ping URL to copy, nothing to keep in sync when the code changes.
What sets it apart
Section titled “What sets it apart”- It reads the resolved schedules.
@Scheduled(cron = "${backup.cron}")is declared with the expression the property actually held, not with the placeholder’s text. - It gives each job a stable identity (
com.acme.jobs.BackupJob#run, orgroup.jobfor Quartz): history survives restarts, redeployments and renames. - It never deletes anything. A job that disappears from the code is flagged orphaned; the history is kept until you decide to delete it.
- It tells environments apart: the same application declared in staging and in production yields two separate checks.
It cannot hurt you
Section titled “It cannot hurt you”A monitoring tool that disturbs production is worse than none. The starter follows strict rules:
- it never fails your job: every error is swallowed and logged at
WARN, and your method is called once, its result and its exception passing through unchanged; - it never blocks your job: sending goes through a bounded queue and a low-priority daemon thread;
- it degrades silently: with no key, no network or no server, the application runs exactly as without it;
silencewatch.enabled: falseremoves the whole mechanism;- it adds no heavy dependency: no JSON library, so no Jackson version is forced on you.
All properties and limits are in the starter documentation.
If your job is not Spring
Section titled “If your job is not Spring”Nothing forces you to use the starter: any job that can make an HTTP request can be monitored with the ping API. See cron job monitoring and the examples.
Frequently asked questions
Section titled “Frequently asked questions”How do I monitor Spring Boot @Scheduled tasks?
Add the SilenceWatch starter and an API key. At startup it discovers @Scheduled methods, declares them with their resolved schedule and sends a heartbeat around every run.
Does the starter also monitor Quartz?
Yes. If Quartz is present, the starter iterates the jobs and reads their triggers; a job with several triggers is declared from the one that fires most often.
Can the starter slow down or crash my application?
No. Network errors are swallowed, sending goes through a bounded queue handled in the background, and with no key or no network the application runs as without the starter. It can be disabled entirely with silencewatch.enabled: false.
What about tasks scheduled programmatically?
Tasks registered through SchedulingConfigurer or lambdas have no stable identity and are ignored by the starter: declare those checks by hand or give them a @Scheduled method.