syslog Table — ServiceNow Reference

Table Reference/syslog

The syslog table stores all server-side log messages generated by gs.log(), gs.info(), gs.warn(), and gs.error() calls. Part of the Platform module. Always query with date ranges and specific filters — this table grows massive at enterprise scale.

What This Table Is

The syslog table captures every server-side log message generated by ServiceNow's logging API calls. When developers call gs.log(), gs.info(), gs.warn(), or gs.error() from Business Rules, Script Includes, or any server-side script, those messages land here. It also captures system-generated log entries from platform operations, workflow activities, and integration failures.

This table belongs to the Platform module and supports debugging and monitoring across the entire ServiceNow instance. It's not part of any specific ITSM process but serves as the central audit trail for all server-side logging activity. System administrators use it for troubleshooting, developers use it for debugging custom scripts, and monitoring teams query it for error patterns.

The syslog table is a standalone table that doesn't extend any parent. No other tables extend it either. Each record represents a single log event with its timestamp, severity level, source, and message content. The table maintains referential links to the user session and source transaction when available.

At enterprise scale, this table grows aggressively. Large instances generate 50,000+ records daily. High-volume integrations, chatty Business Rules, and debug logging can push that to hundreds of thousands of records per day. ServiceNow's log rotation typically keeps 30-90 days of data, but even that represents millions of records. Query performance degrades rapidly without proper date filters.

When You'll Script Against This Table

Most developers query syslog from Script Includes when building debugging utilities, monitoring dashboards, or error reporting scripts. Background Scripts are common for one-off investigations — finding specific error patterns or tracking down performance issues. Scheduled Jobs query it for automated monitoring, sending alerts when error thresholds are exceeded. You rarely hit it from Business Rules or UI Actions since those contexts should be focused on business logic, not log analysis.

Access requires admin role by default. The syslog_reader role provides read-only access for developers who need to query logs without full admin privileges. Global scope scripts have unrestricted access, but scoped applications can only see logs generated within their scope unless explicitly granted cross-scope permissions.

Common scripting patterns:

Debug script troubleshooting — finding your own gs.log() messages from recent test runs
Error pattern analysis — counting specific error types over time periods
Performance monitoring — tracking Business Rule execution times and bottlenecks
Integration debugging — finding failed web service calls and API errors
User session analysis — tracking log entries for specific user activities
Automated alerting — scheduled jobs that detect error spikes and notify administrators
Log cleanup utilities — archiving or deleting old entries beyond retention policies

Table Gotchas

⚠️

Never query syslog without date filters. A simple gr.query() on a production instance can timeout after scanning millions of records. Always use created_on with DATEPART operators or specific date ranges.

The level field stores integer values (0=error, 1=warn, 2=info, 3=debug) not the string labels you see in the UI
Log entries from scoped applications include the scope prefix in the source field — filter carefully to avoid missing entries

⚠️

The message field is truncated at 4000 characters. Long log messages get cut off silently — design your logging calls accordingly.

System-generated entries often have empty user_name fields — background processes and scheduled jobs don't run as specific users
Performance trap: sorting by message content or using CONTAINS queries on the message field bypasses indexes completely

⚠️

Log rotation happens automatically but timing varies by instance. Don't assume logs older than 30 days still exist — check your instance's log rotation policy before building historical reports.

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_user table connects through the user_name field when log entries are generated during user sessions. The sys_user_session table provides session context for understanding user activity patterns that generated specific log entries. These relationships help track down which user actions triggered problematic Business Rules or script execution.

Developers commonly join with sys_script and sys_script_include when the source field references specific script names. This helps identify which Business Rules or Script Includes are generating excessive log entries or throwing errors. The sys_transform_map and sys_import_set tables frequently appear in cross-references since data imports generate substantial logging activity, especially when transformations fail or encounter data quality issues.

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
created_on	glide_date_time	Created	When the log entry was generated. Always query with date filters — this table grows massive and unfiltered queries will timeout.
level	integer	Level	Log severity as integer: 0=error, 1=warn, 2=info, 3=debug. UI shows string labels but queries must use numeric values.
message	string	Message	The actual log message content. Truncated at 4000 characters — longer messages are silently cut off.
source	string	Source	Where the log entry originated — Business Rule name, Script Include, or system process. Scoped app entries include scope prefix.
user_name	string	User name	Username who triggered the logged action. Often empty for system processes, scheduled jobs, and background operations.
session_id	string	Session ID	Browser session that generated the log entry. Useful for tracking user activity patterns but empty for server-side background processes.
transaction_id	string	Transaction ID	Groups related log entries from the same request/response cycle. Critical for debugging complex workflows with multiple script executions.
sequence	integer	Sequence	Order of log entries within the same transaction. Higher numbers indicate later execution in the processing chain.
method	string	Method	HTTP method (GET, POST, PUT) for request-triggered log entries. Empty for background processes and scheduled operations.
url	string	URL	Request URL that triggered the log entry. Helps identify which forms or list views generated specific errors.
user_agent	string	User agent	Browser user agent string from the request. Useful for identifying mobile vs desktop issues or browser-specific problems.
thread	string	Thread	Server thread identifier that processed the request. Advanced debugging field for performance analysis and thread contention issues.
type	string	Type	Log entry category — typically 'system' for platform operations or empty for developer-generated gs.log() calls.
class_name	string	Class name	Java class name for system-generated entries. Usually empty for JavaScript-based Business Rule or Script Include logging.
method_name	string	Method name	Specific method within the class that generated the log entry. Primarily used for Java-based system logging, not custom scripts.

Common Queries

Get recent error-level log entries from the last 24 hours

var gr = new GlideRecord('syslog');
gr.addQuery('level', 0); // 0 = error level
gr.addQuery('created_on', '>=', gs.daysAgoStart(1));
gr.orderByDesc('created_on');
gr.setLimit(100); // Prevent runaway queries
gr.query();

while (gr.next()) {
    gs.info('Error from ' + gr.source + ': ' + gr.message.substring(0, 100));
}

Find log entries by specific user and source in the last week

var gr = new GlideRecord('syslog');
gr.addQuery('user_name', 'admin');
gr.addQuery('source', 'CONTAINS', 'IncidentBusinessRule'); // Match Business Rule names
gr.addQuery('created_on', '>=', gs.daysAgoStart(7));
gr.orderByDesc('created_on');
gr.query();

var count = 0;
while (gr.next() && count < 50) {
    gs.info('User ' + gr.user_name + ' triggered: ' + gr.message);
    count++;
}

Debug specific transaction by finding all related log entries

// Get transaction_id from a known log entry first
var targetTransaction = '01234567890abcdef'; // Replace with actual transaction ID

var gr = new GlideRecord('syslog');
gr.addQuery('transaction_id', targetTransaction);
gr.orderBy('sequence'); // Show chronological order
gr.query();

gs.info('=== Transaction Log Trace ===');
while (gr.next()) {
    gs.info('[' + gr.sequence + '] ' + gr.source + ' (' + gr.level + '): ' + gr.message);
}

Count error entries by source over the last month for monitoring

var ga = new GlideAggregate('syslog');
ga.addQuery('level', 0); // Error level only
ga.addQuery('created_on', '>=', gs.daysAgoStart(30));
ga.groupBy('source');
ga.addAggregate('COUNT');
ga.orderByAggregate('COUNT');
ga.query();

gs.info('=== Top Error Sources (Last 30 Days) ===');
while (ga.next()) {
    gs.info(ga.source + ': ' + ga.getAggregate('COUNT') + ' errors');
}

Wrong vs right way to search log messages — performance gotcha

// WRONG: This will scan every record and timeout
// var gr = new GlideRecord('syslog');
// gr.addQuery('message', 'CONTAINS', 'timeout');
// gr.query();

// RIGHT: Always include date filter first
var gr = new GlideRecord('syslog');
gr.addQuery('created_on', '>=', gs.daysAgoStart(1)); // Filter by date FIRST
gr.addQuery('level', 0); // Then by indexed field
gr.addQuery('message', 'CONTAINS', 'timeout'); // Message search last
gr.setLimit(100); // Always limit results
gr.query();
// Date + level filters eliminate most records before expensive message scan

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

syslog