Development · Lesson

Scheduled jobs

Quick answer

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.

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.

Want to learn this properly?

Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.

See the course Ask a question

Check your understanding

A scheduled job is most like a:
- A. Cron job on a timer
- B. Form
- C. Report filter
Show answer
A. Cron job on a timer
Scheduled jobs run automation on a recurrence.
Which is a good use of a scheduled job?
- A. Nightly data cleanup
- B. Coloring a form
- C. Building an ACL
Show answer
A. Nightly data cleanup
Recurring cleanup is a classic scheduled-job use.
Scheduled scripts run as:
- A. A system user
- B. The last person to log in
- C. Nobody
Show answer
A. A system user
They execute in a system context, not as a person.

Frequently asked questions

What does the term Scheduled jobs refer to in ServiceNow?

Scheduled jobs run work on a timer rather than in response to a record change, nightly cleanups, recurring reports, periodic integrations, escalations.

What is the practical takeaway on Scheduled jobs?

Jobs run periodically (daily/weekly/monthly), once at a set time, or on demand.

What is worth remembering about Scheduled jobs in practice?

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.

What tends to go wrong with Scheduled jobs?

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.