ServiceNow Scheduled jobs: A Practical Guide

ServiceNow Scheduled jobs

Run work automatically on a timer, nightly, hourly, on a schedule.

Quick answer

ServiceNow scheduled jobs run work on a timer rather than on a record change: scheduled script executions, reports emailed as PDF or Excel, data imports, time-triggered flows and cleanup. They obey a time zone, so a midnight job depends on which zone you set. Bound every query with a date filter or setLimit, and log start and finish with counts.

Key takeaways

What can be scheduled
Timing, schedules and time zones
Making jobs safe
Common mistakes
Try it Yourself

Scheduled jobs run work on a timer rather than in response to a record change, nightly cleanups, recurring reports, periodic integrations, escalations. They are how the platform does things while nobody is watching, and getting the cadence, time zone and bounding right is what keeps them from becoming a performance problem.

What can be scheduled

Scheduled Script Execution

Run a server script on a cadence.

Scheduled Report

Email a report as PDF/Excel (see Reporting).

Scheduled Data Import

Run a file/JDBC import on a schedule.

Scheduled Flow

A flow triggered by time.

Data cleanup / rotation

Trim or archive old records.

// Nightly: auto-close incidents resolved 7+ days ago
var gr = new GlideRecord('incident');
gr.addQuery('state', '6');                       // Resolved
gr.addEncodedQuery('sys_updated_onRELATIVELE@dayofweek@ago@7');
gr.query();
while (gr.next()) { gr.state = '7'; gr.update(); }  // Closed

Timing, schedules and time zones

Jobs run periodically (daily/weekly/monthly), once at a set time, or on demand. They obey a time zone, so a "midnight" job depends on which zone you set.

Two classic failures: (1) the time zone is wrong, so the job runs at peak instead of overnight; (2) the query is unbounded and the table has grown, so the job runs for hours and overlaps its next run. Always bound the query and schedule heavy work off-peak.

Making jobs safe

Bound every query, a date filter and/or setLimit() so it can't run away as data grows.
Log progress with gs.info() so a silently failing job is noticed.
Stagger many small jobs rather than one giant one that pins a node.
Consider setWorkflow(false) on bulk writes if you don't want business rules firing per row.

Common mistakes

Ignoring the time zone and scheduling into peak load.
Unbounded queries that grow until the job times out.
No logging, so a broken job goes unnoticed for weeks.
Firing business rules a million times in a bulk update.

Monitoring

Jobs fail quietly unless you make them noisy.

Log a start and finish line with counts, so a silent failure is visible
Alert when a job has not completed within its expected window
Check the scheduler queue when jobs stop running, a stuck job blocks the worker
Review the job list yearly, most instances carry jobs nobody remembers creating

Try it YourselfJavaScript

▸ Press Run to execute.

Runs in a sandbox in your browser. Mock gs and GlideRecord and sample data are provided.