Docs › Quartz Scheduler monitoring with RunVouch

Quartz Scheduler monitoring with RunVouch

Quartz Scheduler monitoring for the misfire policy you did not choose: a CronTrigger that could not fire on time (scheduler paused, no free worker thread, JVM down) is a misfire after the threshold (60 seconds by default), and what happens next is the trigger's misfire instruction: fire once now, or do nothing until the next time. Either way, Quartz logs it and nobody is told.

How it runs on Quartz Scheduler

At the top and bottom of the job's execute(), or in a JobListener (jobToBeExecuted / jobWasExecuted) that covers every job in the scheduler. The listener gets the JobExecutionException, so status is exact.

Store the key

RUNVOUCH_KEY from the environment or the scheduler's SchedulerContext, set at boot; not in quartz.properties.

Report the run (two HTTP calls)

// one listener for every job in the scheduler
public class RunVouchListener implements JobListener {
  static final String API = "https://api.runvouch.com";
  final HttpClient http = HttpClient.newHttpClient();
  final String key = System.getenv("RUNVOUCH_KEY");
  public String getName() { return "runvouch"; }

  String post(String path, String body) {
    try {
      var req = HttpRequest.newBuilder(URI.create(API + path)).timeout(Duration.ofSeconds(10))
          .header("X-API-Key", key).header("content-type", "application/json")
          .POST(HttpRequest.BodyPublishers.ofString(body)).build();
      return http.send(req, HttpResponse.BodyHandlers.ofString()).body();
    } catch (Exception e) { return "{}"; }                        // fail open
  }
  public void jobToBeExecuted(JobExecutionContext ctx) {
    String agent = ctx.getJobDetail().getKey().getName();          // e.g. nightly-report
    String r = post("/v1/runs/start", "{\"agent\":\"" + agent + "\",\"source\":\"quartz\"}");
    ctx.put("rv_run_id", r.replaceAll(".*\"run_id\":\"([^\"]+)\".*", "$1"));
  }
  public void jobExecutionVetoed(JobExecutionContext ctx) {}
  public void jobWasExecuted(JobExecutionContext ctx, JobExecutionException e) {
    Object result = ctx.getResult();                               // set by the job: rows written
    boolean ok = e == null, ev = result instanceof Integer && (Integer) result > 0;
    post("/v1/runs/end", "{\"run_id\":\"" + ctx.get("rv_run_id") + "\",\"status\":\"" + (ok ? "ok" : "fail")
        + "\",\"evidence\":{\"rows_written\":" + ev + "}}");
  }
}
// scheduler.getListenerManager().addJobListener(new RunVouchListener(), EverythingMatcher.allJobs());
// trigger: cronSchedule("0 0 2 * * ?").withMisfireHandlingInstructionDoNothing()
// rv agent nightly-report --cadence 24h --grace 30m --evidence

The start call returns run_id; the end call takes status (ok or fail), optional cost and tokens, and evidence as a JSON object of booleans. Full reference on the API page.

Register the cadence and caps

rv agent nightly-report --cadence 24h --grace 30m --max-runtime 1h --evidence --cap-run-cost 2

Register the agent once, from anywhere with the key. Cadence is what turns a schedule that stopped into an alert; --evidence makes a run without evidence a failure; the caps pause the agent when it overspends.

What goes silent on Quartz Scheduler

• A misfire with withMisfireHandlingInstructionDoNothing() skips the run; with the default smart policy it fires once, late. Only MISSED (measured from outside) tells you which happened tonight.
• RAMJobStore (the default) keeps triggers in memory; a restart without re-registering them means no schedule. JDBCJobStore survives, if the scheduler is started.
• A job that catches its exception and returns is a completed job; a job that throws JobExecutionException with refireImmediately loops on the same input, which is RETRY_STORM when reported per attempt.
• A thread pool exhausted by long jobs delays every trigger; STALLED on the long ones, MISSED on the delayed ones.

What Quartz Scheduler does not tell you

Quartz logs misfires and job exceptions through SLF4J and exposes listeners for jobs, triggers and the scheduler; it has no notification of its own and no built-in record that a trigger was supposed to fire while the scheduler was down. The QRTZ_FIRED_TRIGGERS table (JDBC store) shows what is running now, not what did not run. A job's result object is whatever the job set, and by default nothing reads it.

What RunVouch detects

Set up in two minutes

1. Get a free key (3 agents, no card) and store it where this page says.
2. report the run (two http calls): copy the snippet above into the scheduled job.
3. Register the cadence once: rv agent nightly-report --cadence 24h --grace 30m --evidence, or let the first run create the agent and set the cadence on the dashboard.
4. Send one test alert: curl -X POST https://api.runvouch.com/v1/settings/test-alert -H "X-API-Key: $RUNVOUCH_KEY". The next missed, failed or empty run reaches the same channels.

Need a key? Get a free key · Stuck? contact