Why Your Spring Boot Batch Job May Need Its Own Deployment

A technical analysis warns that embedding scheduled batch jobs inside a main Spring Boot application can cause serious resource and reliability issues. Because containers must be sized for peak memory usage, every API replica ends up reserving batch-level memory around the clock, even when the job runs only once nightly. If the batch job's memory consumption spikes beyond the container limit, the kernel kills the process with a silent exit code 137, leaving no useful logs or stack traces. GC pressure from heavy batch allocations can also degrade API response latency during off-hours without any obvious connection to the job. The post recommends extracting batch jobs into standalone processes using CommandLineRunner or Spring Batch, disabling the embedded web server where possible, and reserving the co-located approach only for genuinely simple, low-memory workloads.