What is Scheduled Job?
Also called scheduled task, batch job, recurring job.
A scheduled job is work that runs automatically at defined times or intervals rather than in response to a user request. Typical uses include generating reports, synchronizing data, sending digests, cleaning up expired records, and triggering recurring agent tasks. Because no person is waiting on the result, failures are easy to miss unless the schedule is explicitly monitored.
Scheduling introduces questions that request driven code never faces. What happens when a run is still going when the next one is due, whether to skip, queue, or run in parallel. What happens to runs missed while the system was down, whether to backfill or ignore. Which time zone the schedule is interpreted in, and how daylight saving transitions are handled, since a local time schedule can skip or repeat an hour twice a year.
Silent failure is the characteristic risk. A user facing endpoint that breaks generates complaints within minutes, while a nightly job that stops running may go unnoticed for weeks until someone asks why a report looks stale. The standard mitigation is monitoring for absence rather than for errors: alert when an expected run has not completed within its window, not only when a run reports a failure.
Scheduled jobs concentrate load, which makes them a common source of capacity incidents. Many schedules default to the top of the hour or midnight, so unrelated jobs pile up at the same instant and contend for the same database and workers. Spreading start times, adding jitter, and limiting the concurrency of any single job class keeps a schedule from behaving like a self inflicted traffic spike.
For agent platforms, scheduled jobs are how recurring autonomous work is triggered: a daily summary, a weekly audit, a periodic inbox scan. Because each triggered run consumes metered model usage, schedules deserve explicit cost limits. A schedule that fires more often than intended, or fans out across many accounts at once, can multiply usage quickly and quietly.
Key points
- Runs on a timer rather than in response to a request.
- Define overlap, catch up, and time zone behavior explicitly.
- Alert on a missing run, not only on a failed one.
- Stagger start times to avoid synchronized load spikes.
- Recurring agent runs consume metered usage on every trigger.
In practice
A weekly digest job runs Monday at 07:00 in each workspace's local time zone. The scheduler starts one run per workspace, staggered across a fifteen minute window so the database is not hit by every query at once. If a run has not completed within two hours of its scheduled start, monitoring raises an alert. Overlapping runs are skipped rather than queued, since a duplicate digest is worse than a late one.