Master the Batch Command in Linux Quickly

The batch command is a useful Linux utility that lets you schedule a job to run only when the system is not busy. Instead of running a task immediately or at a fixed time, batch waits until the system load drops to a safe level before starting it.

In this guide, you'll learn what the batch command is, how it works, its syntax, common options, practical examples, and when to use it instead of cron, at, or running a command directly in the background.

Examples

batch reads a list of shell commands and runs them later, once your system's load average drops low enough that running them will not choke everything else. That's it. No cron syntax, no fixed clock time, just "run this when things calm down."

Under the hood, batch is not really its own program. It is a thin wrapper around at, and both are managed by the same background daemon, atd. When you submit a job with batch, it lands in a special queue (queue "b" by convention) and atd checks periodically whether the load average is low enough to let it run. The exact threshold is not something batch decides on its own, it depends on how atd was compiled and configured on your distro, which is why you will see different numbers quoted in different places (0.8 on some systems, 1.5 on others).

If you have ever run a heavy job over SSH and then had someone else on the team ping you asking why their deploy is crawling, that's the exact situation batch was built to prevent.

The command itself takes almost nothing on the command line. You call it, then type or pipe in the commands you want executed:

Notice there is no "at 5pm" or "in 2 hours" anywhere in that syntax. That part is the whole point. You are not telling the system when to run the job, you are telling it to run whenever it is safe to, and atd decides the rest based on load average.

You can also skip the interactive prompt entirely and pipe commands straight in, which is what most people actually use in scripts:

batch does not have a long flag list the way ls or find do. It borrows most of its behavior from at, and only a handful of flags are worth remembering day to day.

The most basic use, good for testing that batch and atd are even working on your box.

You are not limited to one line. Keep typing and each line becomes part of the same job.

Once your batch job gets past two or three lines, stop typing it interactively and keep it in a file.

batch jobs share the same queue system as at, so you check them the same way.

When you use the -v flag, the terminal prints the exact submission timestamp the moment you hit Enter, before you even type your commands. It's not a forecast of when the job will run, it's just confirmation of the time atd recorded the submission against.

Most servers don't have local mail configured, which means batch's default habit of mailing you the output goes nowhere. Redirect it yourself.

Queued something by accident, or the load never actually needed easing? Pull the job number from atq and drop it.

On a CI server that spikes hard during build windows, you don't want a manual compression job stepping on top of an active build.

A media processing job that eats CPU for twenty minutes should not go anywhere near a system while it's already under load from render jobs.

If your cron jobs already fire on the hour and a manual export needs to slot in around them without fighting for CPU, batch is a cleaner fit than trying to guess a free minute.

This is the single most common thing people get wrong the first time they touch batch.

The fix is one of the two patterns already used throughout this article, either run batch alone and type the command on the next line, or pipe it in with echo:

Without something like batch, "run this when the server isn't busy" turns into a guessing game. You either babysit top or htop waiting for a quiet window, or you just run the job anyway and hope nobody notices the slowdown. On a box that anyone else depends on, that second option eventually burns you.

What batch unlocks is the ability to hand off that judgment call to the system itself. You stop being the one deciding when load is "low enough" and let atd make that call every few minutes based on actual numbers, not a guess from watching a dashboard for thirty seconds. Once you get comfortable with that, you start reaching for it any time a task is heavy but not urgent, log rotation, report generation, batch encoding, anything that can wait a bit but shouldn't wait forever.

Once batch clicks, it tends to change how you think about scheduling anything heavy. Instead of asking "when should this run," you start asking "does this even need a fixed time, or can I just let the system decide." For deeper background on how atd makes that decision, the official batch man page is worth a read once you've run a few jobs yourself. If you want to compare this against recurring scheduling, our guide on moving from cron jobs to systemd timers covers the other side of that decision, and anacron is worth knowing about too if your systems aren't always powered on.

Before you queue anything heavy, it also helps to actually understand what load average means in the first place, our system monitoring command cheat sheet and the htop command guide both cover how to read those numbers in real time. And since most batch jobs are really just shell scripts wearing a queue ticket, brushing up on exit codes and error handling and logging best practices will save you from the classic "did it even run" problem. If you want the full picture of related commands in one place, the shell scripting command cheat sheet is a solid bookmark, and these beginner shell scripting interview questions often touch on job scheduling if you're prepping for a sysadmin interview.