Trace the call in the guide's own sample. `jobLauncher.run` throws, the catch block logs the exception, and the method returns normally [16]. The comment sitting in that catch block says what follows: no alert, no retry, no escalation [16]. To the scheduler, the invocation completed, which is the "returns success" the guide puts at the centre of the problem [1]. Anything layered above consumes the same signal. Teams bolt on Actuator, custom logging and Micrometer, and the guide's own verdict is that by the time there is real observability it is a custom framework to maintain [9]. A framework you did not plan to write is still a framework you keep patched.
The interval is what costs money. The sample runs on cron `0 0 2 * * *`, once a night, chunk size 500 [15]. The guide says data corruption from concurrent runs can take weeks to surface [3]. Take two weeks as the low end of that: one run a night for fourteen nights is fourteen executions writing against corrupted state before anyone reads the evidence [1].
Durable execution changes where the history lives. Temporal records every state transition to an event log, and a crashed process is recovered by replaying that log and resuming from the point it stopped [5][6]. The observability is a byproduct of the recovery mechanism: a log detailed enough to reconstruct an execution is detailed enough to answer which step ran and how it ended [2]. Compare that with `BATCH_JOB_INSTANCE` and `BATCH_JOB_EXECUTION`, which the guide notes you manage, prune and keep consistent yourself [13].
The requirement the guide leaves implicit sits in your code. If resuming means replaying recorded state transitions through the same plain Java methods, those methods have to reach the same points in the same order when they are re-executed [3]. That constraint decides whether a given job is a straightforward port or a redesign.
The piece carries no measured numbers, only a before/after diagram and code [19], so nothing here transfers as a benchmark; what transfers is the failure taxonomy, and only if your jobs have the same shape. The guide is straight about that: `@Scheduled` is fine for one or two simple jobs, and the debt accumulates by the time a team has dozens [8]. In my context, a dozen-plus jobs whose only witness is a log line, a queryable execution history is worth the port. At three jobs, the scheduler you already run plus a lock library is the cheaper answer, and the guide concedes that the lock approach works [11].
