A scheduled job runs a script on a schedule, such as cleaning up stale records or sending digests. It is the platform’s cron, and the same cautions apply: jobs that run long, overlap or fail quietly cause problems out of proportion to their simplicity.
Before you start
You should be comfortable with server-side scripts and GlideRecord. This article covers scheduled jobs and their pitfalls.
Step-by-step walkthrough
Step 1: Keep the job bounded and idempotent
Set a condition so the job processes only what it should, and cap the batch so a single run does not scan a huge table. Make it idempotent, so a rerun after a failure does not double-process records.
Step 2: Prevent overlap and runaway runs
A job that runs longer than its interval can start again before the previous run finishes, causing duplicate work. Set a maximum run time and, where needed, a flag to skip a run if the previous is still active. Long synchronous jobs also hold resources and can time out.
Step 3: Log and handle errors
Log what the job did, how many records it processed and any failures, so a silent failure is visible. Wrap risky work so one bad record does not abort the whole run, and record errors for follow-up.
Worked scenario
The job processes a bounded batch and logs the result.
var gr = new GlideRecord('incident');
gr.addQuery('state', 'closed');
gr.addQuery('closed_at', '<', gs.daysAgo(90));
gr.setLimit(500);
gr.query();
var count = 0;
while (gr.next()) { count++; /* archive or delete */ }
gs.info('archive job processed ' + count + ' records');Walk through the example
The query is bounded by state, age and a limit, so the run is predictable. Logging the count makes the job’s behavior visible, and a failure on one record can be caught without aborting the rest. The design keeps the job short and observable.
Common mistake
A job that scans the whole table without a limit, which runs long and may overlap the next occurrence. Another is swallowing exceptions so a failing job appears to succeed, and no one notices the backlog.
Verify the behavior
Run the job manually and confirm it processes the expected records and logs a count. Check that a rerun does not double-process. Observe timing and confirm it finishes within the interval.
Interview exercise
Why is overlap dangerous for a scheduled job?
Answer and reasoning
If a run takes longer than the interval, the next run starts while the first is still working, so two runs process the same records and can duplicate work or corrupt results. Bounding the run time and skipping overlapping runs keeps each execution independent. Idempotency is the safety net when overlap still occurs.
Continue learning
Compare timing in Business rule timing and cleanup in Update sets. Read the ServiceNow scheduled jobs documentation and try the ServiceNow interview questions.