sysauto_script Table — ServiceNow Reference

Table Reference/sysauto_script

The sysauto_script table manages scheduled scripts that run on cron schedules, owned by the Platform module. Before querying it, know that this table doesn't run the scripts — it just stores the configuration and execution metadata.

What This Table Is

The sysauto_script table stores scheduled script executions — automated tasks that run on cron schedules to perform system maintenance, data cleanup, and recurring business logic. Each record defines a script to execute, when to run it, and tracks execution history including last run time and next scheduled execution.

Owned by the Platform module, this table supports ServiceNow's built-in scheduled job framework. The scheduler service reads these records and executes the JavaScript code at the specified intervals. Common uses include data archiving, cache clearing, integration synchronization, and automated report generation.

The table extends sys_metadata but doesn't have child tables extending it. Records are scoped to the application that creates them, though global scheduled scripts can access any scope. The table integrates tightly with the sys_trigger table for execution scheduling and the syslog table for execution logging.

Most instances have 20-50 scheduled script records, though large enterprises may run 100+ automated jobs. Performance is rarely an issue since the scheduler processes records sequentially, but poorly written script content can impact system performance when executed.

When You'll Script Against This Table

You'll typically script against sysauto_script in Script Includes that manage scheduled jobs programmatically, Business Rules that trigger when job configurations change, and REST APIs that expose scheduling functionality. Administrative scripts often query this table to audit scheduled jobs or temporarily disable problematic scripts.

Access requires the admin role by default, as scheduled scripts can execute privileged operations. The script field containing the JavaScript code is particularly restricted and may not be readable in scoped applications without elevated privileges.

Create scheduled jobs programmatically through REST or script
Monitor job execution status and last run times
Temporarily disable jobs during maintenance windows
Audit scheduled job configurations across applications
Update job schedules based on business rule triggers
Clone or template scheduled jobs for new environments
Generate reports on automated job frequency and performance

Table Gotchas

⚠️

The script field stores JavaScript as a string but executes in global scope regardless of the record's application scope. Scoped app scripts can access global APIs they normally couldn't reach.

The active field doesn't immediately stop running jobs — the scheduler checks this flag before the next execution, not during current execution

⚠️

Updating the run_time field doesn't reschedule the job. You must also update the sys_trigger record or use the ScheduledJobManager API to change execution timing.

The last_run timestamp updates even if the script throws an exception — check syslog for actual execution results
Queries against script field content are expensive — the field isn't indexed and contains large text blocks

⚠️

Deleting sysauto_script records leaves orphaned sys_trigger records. The jobs won't execute but the triggers remain in the queue until manually cleaned up.

The run_as field only affects script execution context when populated — empty values run as system, not the job creator

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The sys_trigger table maintains the actual execution schedule for each scheduled script, storing next run time and trigger state. The syslog table captures execution results, errors, and performance metrics for each job run. Both tables reference sysauto_script records to provide complete job lifecycle management.

When scheduled scripts modify data, developers commonly join sysauto_script with target tables like task or custom application tables to audit automated changes. The sys_user table links through the run_as field to track execution context and permissions.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Name	Unique identifier for the scheduled job. Must be unique across the system and is used by APIs to reference specific jobs.
active	boolean	Active	Controls whether the job executes on schedule. Changes take effect before the next scheduled run, not immediately for currently running jobs.
script	script_plain	Script	JavaScript code to execute. Runs in global scope regardless of application scope, with full system privileges unless run_as is specified.
run_time	string	Run time	Cron expression defining when the job runs. Modifying this field requires updating the associated sys_trigger record to take effect.
run_as	reference	Run as	Reference to sys_user for execution context. Empty values run with full system privileges, not as the job creator.
last_run	glide_date_time	Last run	Timestamp of most recent execution attempt. Updates even if the script fails or throws an exception.
run_start	glide_date_time	Run start	When the current or last execution began. Used to detect long-running or stuck jobs.
run_type	choice	Run type	Execution mode: 'on_demand' for manual runs, 'periodically' for scheduled execution, or 'once' for single execution.
conditional	conditions	Condition	Optional condition that must evaluate true before script execution. Checked each time before the job runs.
description	string	Description	Human-readable description of the job's purpose. Critical for maintenance since job names are often cryptic technical identifiers.
job_context	string	Job context	Additional context passed to the executing script. Accessible within the script but rarely used in practice.
run_dayofweek	integer	Run day of week	Day of week for weekly schedules (0=Sunday). Only relevant when run_time uses weekly cron patterns.
run_dayofmonth	integer	Run day of month	Day of month for monthly schedules. Only relevant when run_time uses monthly cron patterns.
upgrade_safe	boolean	Upgrade safe	Whether the job should run during platform upgrades. Set to false for jobs that might conflict with upgrade processes.
time_zone	string	Time zone	Time zone for schedule interpretation. Defaults to system time zone if not specified, which can cause confusion across regions.

Common Queries

Get all active scheduled scripts

// Most basic query - shows all jobs that will execute
var gr = new GlideRecord('sysauto_script');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    gs.info('Active job: ' + gr.getValue('name'));
    gs.info('Last run: ' + gr.getValue('last_run'));
    gs.info('Schedule: ' + gr.getValue('run_time'));
}

Find jobs that haven't run in 24 hours and are active

// Identify potentially stuck or failing jobs
var yesterday = new GlideDateTime();
yesterday.addDaysUTC(-1);

var gr = new GlideRecord('sysauto_script');
gr.addQuery('active', true);
gr.addQuery('last_run', '<', yesterday);
gr.addQuery('run_type', 'periodically'); // Skip on-demand jobs
gr.query();

while (gr.next()) {
    gs.warn('Stale job detected: ' + gr.getValue('name'));
    gs.warn('Last run: ' + gr.getValue('last_run'));
}

Get jobs running as specific user with their execution history

// Audit jobs by execution context - useful for security reviews
var targetUser = 'admin'; // or specific user sys_id

var gr = new GlideRecord('sysauto_script');
gr.addQuery('run_as', targetUser);
gr.addQuery('active', true);
gr.orderByDesc('last_run');
gr.query();

while (gr.next()) {
    gs.info('Job: ' + gr.getValue('name') + ' runs as ' + gr.getDisplayValue('run_as'));
    gs.info('Description: ' + gr.getValue('description'));
    gs.info('Schedule: ' + gr.getValue('run_time'));
}

Count scheduled jobs by run type and status

// Get overview of job distribution for capacity planning
var agg = new GlideAggregate('sysauto_script');
agg.addAggregate('COUNT');
agg.groupBy('run_type');
agg.groupBy('active');
agg.query();

while (agg.next()) {
    var runType = agg.getValue('run_type');
    var active = agg.getValue('active');
    var count = agg.getAggregate('COUNT');
    
    gs.info('Run type: ' + runType + ', Active: ' + active + ', Count: ' + count);
}

Wrong way vs right way to find jobs by script content

// WRONG: Expensive query against script field
// var gr = new GlideRecord('sysauto_script');
// gr.addQuery('script', 'CONTAINS', 'someFunction');

// RIGHT: Use name or description for filtering, then check script
var gr = new GlideRecord('sysauto_script');
gr.addQuery('name', 'CONTAINS', 'cleanup'); // Use indexed fields first
gr.query();

while (gr.next()) {
    // Then check script content in memory
    if (gr.getValue('script').indexOf('someFunction') > -1) {
        gs.info('Found job with function: ' + gr.getValue('name'));
    }
}

Related Tables

sys_trigger syslog sys_user

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue