GlideSystem.error() — ServiceNow API

gs.error(message, parameters)→ void

beginnerTested on Xanadu

What It Does

The gs.error() method writes messages to the ServiceNow system log at ERROR severity level. When called, it creates a log entry in the System Logs [sys_log] table with severity 'error' and stores the formatted message along with timing, user context, and script location metadata.

ServiceNow's logging framework processes the message through its substitution engine, replacing numbered placeholders with the provided parameters. The platform automatically escapes HTML entities and special characters to prevent log injection attacks. The final formatted message gets written to both the database log table and any configured external log collectors.

The method returns void and never throws exceptions, even if the logging system fails. Script execution continues normally after calling gs.error(). This makes it safe to use for defensive logging without worrying about breaking business logic flow.

ERROR level messages have special platform behavior compared to other log levels. Many ServiceNow monitoring tools and alerting systems default to watching for ERROR entries. In production environments, ERROR logs often trigger notifications to system administrators and can influence health dashboards and SLA calculations.

The method belongs to the same logging family as gs.info(), gs.warn(), and gs.debug(). All use identical parameter substitution syntax but differ in severity level and platform handling. ERROR sits at the highest severity, making it the most visible in monitoring systems.

When to Use This

Use gs.error() for unexpected failures that indicate something is genuinely wrong but don't require halting execution. Examples include failed external API calls, missing expected configuration data, invalid user input that can't be processed, or database operations that should have succeeded but didn't. These are conditions that operations teams need to know about but that your script can work around or handle gracefully.

Don't use gs.error() for expected business logic conditions or validation failures that users might trigger through normal application use. Use gs.info() or gs.warn() instead. Also avoid it when you need to actually stop execution - gs.error() logs and continues, it doesn't throw exceptions or halt processing.

A common misuse pattern is logging every validation error as ERROR level. Reserve ERROR for system-level problems, not user-level problems. Form validation failures, missing required fields, or permission denials are normal application behavior and should use lower severity levels that don't trigger production alerts.

Return Value

The method returns void (undefined in JavaScript terms). There is no return value to capture or check. The method performs its logging operation as a side effect and provides no feedback about whether the logging succeeded or failed.

Because logging failures are handled silently by the platform, your script won't know if disk space issues, database problems, or permission restrictions prevented the log entry from being written. This fire-and-forget design ensures that logging problems never break business logic, but means you can't programmatically verify that important error messages were successfully recorded.

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.

Platform Behavior & Side Effects

Creates a new record in the System Logs [sys_log] table with severity 'error' and current timestamp
Triggers any configured log forwarding to external SIEM or monitoring systems
May activate email notifications or alerts if instance has ERROR-level log monitoring configured
Does not trigger Business Rules, ACLs, or other record-based security mechanisms
Performance impact is minimal - logging operations are asynchronous and don't block script execution
Log entries include automatic context like current user, session ID, and script execution location
Behaves identically across all server-side contexts - Business Rules, Script Includes, Scheduled Jobs, etc.

Parameters

Name	Type	Required	Description
message	string	Yes	The error message to log. Can contain placeholders like {0}, {1} for parameter substitution. HTML and special characters are automatically escaped when logged.
parameters	any	No	Optional parameter(s) to substitute into the message placeholders. Can be a single value or comma-separated values. Objects are converted to strings using their toString() method.

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

Code Examples

Basic error logging with parameter substitutionbasic

// Business Rule on incident table - before insert
// Validate that critical incidents have proper assignment

if (current.priority == 1 && current.assigned_to.nil()) {
    // Log the error with incident number for tracking
    gs.error('Critical incident {0} submitted without assignment. Reporter: {1}', 
             current.number, current.caller_id.getDisplayValue());
    
    // Continue processing - don't fail the insert
    // But ensure operations team knows about it
    current.assignment_group = gs.getProperty('incident.critical.default_group');
}

// Log successful processing for audit trail
if (current.priority == 1) {
    gs.info('Critical incident {0} processed successfully', current.number);
}

This shows proper ERROR usage for system-level problems that need attention but shouldn't halt processing. The parameter substitution makes logs searchable and actionable.

External integration error handlingintermediate

// Script Include for external API calls
var IntegrationHelper = Class.create();
IntegrationHelper.prototype = {
    
    syncUserData: function(userSysId) {
        var user = new GlideRecord('sys_user');
        if (!user.get(userSysId)) {
            gs.error('User sync failed - invalid sys_id: {0}', userSysId);
            return false;
        }
        
        try {
            var response = this._callExternalAPI(user);
            if (!response || response.status != 200) {
                gs.error('External API sync failed for user {0}. Status: {1}, Response: {2}',
                        user.getDisplayValue(), response.status, response.body);
                return false;
            }
        } catch (ex) {
            gs.error('Exception during user sync for {0}: {1}', 
                    user.getDisplayValue(), ex.message);
            return false;
        }
        
        return true;
    }
};

ERROR level is appropriate here because external API failures are unexpected system problems that operations needs to investigate, not normal business logic flows.

The Classic Mistake - overusing error leveladvanced

// WRONG - Don't do this
if (current.caller_id.nil()) {
    gs.error('User must provide caller ID'); // This is validation, not an error!
    return false;
}

// RIGHT - Use appropriate log levels
if (current.caller_id.nil()) {
    gs.warn('Incident {0} submitted without caller ID, using system default', 
           current.number);
    current.caller_id = gs.getProperty('incident.default.caller');
}

// Use ERROR for genuine system problems
var defaultCaller = new GlideRecord('sys_user');
if (!defaultCaller.get(gs.getProperty('incident.default.caller'))) {
    gs.error('System configuration error - default caller {0} not found', 
            gs.getProperty('incident.default.caller'));
    // This IS an error - system config is broken
}

The first example creates alert fatigue by logging normal validation as errors. Reserve ERROR for actual system problems that indicate broken configuration or infrastructure.

Gotchas

ERROR logs may trigger production alerts and wake up on-call engineers, so use sparingly for genuine system problems.

Parameter substitution happens even if the log level is disabled, so expensive operations in parameters still execute.

Log entries are written asynchronously and may not appear immediately in the System Logs table.

Very long messages (over 4000 characters) get truncated silently without any indication in the logs.

Object parameters get converted using toString() which may not give you the data you expect - convert to strings explicitly.

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