Does Quartz Remember Between Runs? A Job Store Saves the Schedule and a Small Map. The Next Job Still Starts as a New Instance.

Quartz can remember a schedule across a restart, and with the right annotation it can carry a small map of values from one execution to the next. Neither fact makes a job itself remember. Every time a trigger fires, Quartz creates a new instance of the job class, calls execute, and drops that instance when the run ends. Anything the previous run reasoned through, unless it was deliberately written into the one narrow place Quartz persists, is not waiting for the next run.

A new instance on every firing

The job lifecycle is the starting point. Quartz does not keep a job object alive between firings. The scheduler asks its job factory for a fresh instance, the instance runs, and then it is gone. That is why the official guidance is blunt about fields: data fields defined on the job class do not make sense as state, because their values are not preserved between executions.

A field set during a Monday run reads as its default on Tuesday. A list built up during one execution does not grow across executions. If state needs to survive, Quartz points to exactly one built-in home for it, and that home is not the job object.

The JobDataMap: configuration first, state by opt-in

That home is the JobDataMap. A JobDetail carries one map, and a trigger can carry its own map as well. At execution time the job receives a merged map built from both, and when the same key appears in both places, the trigger value wins. The map holds serializable key-value entries, with convenience accessors for strings, numbers, dates, and other primitive types.

Used in its default form, the map is configuration. It answers questions set at scheduling time: which customer ID to process, which date range to cover, which mode to run in, which endpoint to call. The job reads those values, does its work, and any changes it makes to the map during the run are thrown away when the run ends. The next firing reads the originally stored values again.

State between executions requires an explicit opt-in. Marking a job with @PersistJobDataAfterExecution tells Quartz to update the stored JobDataMap of the JobDetail after execute completes, so the next execution receives the updated values instead of the original ones. That update happens even when the job throws a JobExecutionException. The pattern pairs strongly with @DisallowConcurrentExecution, which prevents two instances of the same job definition from running at once. Without that pairing, two concurrent executions can race, and whichever one finishes last decides which map is left stored.

Even with both annotations, the map stays a map. It carries a counter, a watermark, or a last-processed ID cleanly. It is a poor home for a growing narrative: what an AI step checked, why it chose one record over another, and what a human corrected in the meantime.

Where the map lives: RAMJobStore or a JDBC store

Persistence also depends on the job store. RAMJobStore keeps jobs, triggers, and their data in memory inside the running process. It is simple and fast, and a restart clears it. A JDBC job store writes the same records to a database, so schedules survive restarts and can be shared across clustered nodes.

The database route changes what the map can hold. With a persistent store, JobDataMap values are serialized, so every value must be serializable, and serialized classes create versioning risk: change the shape of a stored class and older stored values can fail to load. Quartz can be configured so the store accepts only primitives and strings, which removes that class of failure and also underlines the intended shape of the data. IDs and simple values travel well. Rich context does not belong in the record.

Durability and recovery follow the same logic. A job marked to request recovery can be re-executed after a hard shutdown, with the context flagging that it is recovering. Quartz remembers that an execution was interrupted. It does not rebuild what that execution had figured out.

Where this leaves scheduled AI work

Consider a recurring AI job built on Quartz: a nightly review that checks new records, drafts summaries, and flags exceptions. The schedule is reliable, and the inputs in the map arrive exactly as stored. Then the useful questions start. Which records did last night's run already flag? Which summary did it send, so tonight's note builds on it instead of repeating it? What did a reviewer correct yesterday?

Quartz gives clean answers for the schedule and narrow answers for state. A counter can say how many runs happened. A watermark can say where processing stopped. Neither carries the reasoning, the wording, or the corrections. Teams usually respond by building the missing layer by hand: a table for run history, a file for summaries, a prompt assembled from fragments at the start of every run.

A memory layer the next run can actually read

Vilix AI is built for that missing layer. It is cloud-hosted with zero infrastructure to manage, so a Quartz job, a script, and a chat tool can all reach the same memory without a new store to run or maintain. The memory follows over MCP, which means the same memory is available everywhere the work happens, not locked inside one scheduler, one process, or one application.

The shape of what is stored matters as much as where it lives. Vilix AI keeps full conversation history, not just extracted facts, so a later run can revisit what was actually said, decided, and corrected, in context. A nightly job can save its real working history at the end of a run, and the next firing can load the relevant history at the start: records already handled, language already approved, exceptions already raised, and decisions already made. The JobDataMap can stay what it is good at, small scheduling inputs and a watermark, while the working memory lives in a layer designed to hold it.

Getting started is kept deliberately light. Vilix AI has a free plan forever, and Pro offers a 7-day trial with no credit card required. Data stays under the user's control, with the ability to export everything or delete it anytime. A scheduled workflow can begin with the free plan, connect over MCP, and test the pattern on one recurring job before wider use.

The short answer

Does Quartz remember between runs? It remembers the schedule, the triggers, and the job definition. It remembers a JobDataMap, and with @PersistJobDataAfterExecution it can update that small map after each run so simple values carry forward. It does not remember the job instance, its fields, or the work the last run did beyond what was deliberately flattened into that map. For counters and watermarks, that is enough. For scheduled AI work that needs its own history back, the memory needs to live outside the job, in a shared layer like Vilix AI that every run and every tool can read.