GlideSystem.info() — ServiceNow API

gs.info(message, parameters)→ void

beginnerTested on Xanadu

What It Does

The gs.info() method writes messages to ServiceNow's application log at the INFO level. Unlike debug or error messages, INFO level logs are always written regardless of debug settings, making them suitable for production logging of important application events.

Internally, ServiceNow processes the message through its logging subsystem, applying any configured log filters and routing rules. The message gets timestamped, tagged with the current user context, and written to the syslog table where it's accessible through System Logs → System Log → App Logs.

The method returns void (undefined in JavaScript terms) and never throws exceptions, even when passed invalid parameters. If the message parameter is null or undefined, ServiceNow logs an empty string. Parameter substitution uses zero-based indexing with curly brace notation: {0}, {1}, etc.

Edge cases include behavior when substitution tokens don't match provided parameters. Unused tokens remain as literal text in the final message, while extra parameters beyond the highest token index are ignored. Object parameters get serialized using JSON.stringify() when possible, falling back to [object Object] for complex objects that can't be serialized.

This method is part of the GlideSystem logging family alongside gs.log(), gs.warn(), gs.error(), and gs.debug(). The key difference is that gs.info() includes built-in string substitution and is the recommended choice for scoped applications.

When to Use This

Use gs.info() when you need to log important application events that should always be recorded, such as successful integrations, user actions, or workflow completions. This is the correct method for production logging where you need visibility into application behavior without the verbosity of debug logs or the alarm-level nature of error logs.

Choose gs.debug() instead for temporary troubleshooting messages that should be filtered out in production. Use gs.error() for genuine error conditions that require attention. Avoid using gs.log() in scoped applications since it doesn't support message substitution and creates less organized log entries.

Common misuse includes logging sensitive data like passwords or API keys, logging inside tight loops without throttling, and using INFO level for debugging messages that should use DEBUG level. Resist the temptation to log every variable value during development - use appropriate log levels to keep production logs clean.

Return Value

The method returns void (JavaScript undefined) in all cases. The method never fails or throws exceptions, even when passed invalid arguments or when the logging subsystem encounters errors. This fire-and-forget design prevents logging code from breaking your business logic.

Since there's no return value to check, you cannot programmatically determine whether the log message was successfully written. If you need confirmation that logging occurred, check the System Logs manually or use a custom logging solution that provides feedback.

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 record in the syslog table with level 'INFO', source script name, and full user context
Does not trigger Business Rules, ACLs, or notifications - logging is considered a system-level operation
Performance impact is minimal but accumulates - each call requires string processing and database write
Works identically in all server-side contexts - Business Rules, Script Includes, Scheduled Jobs, and UI Actions
Log entries are subject to ServiceNow's automatic log rotation and cleanup policies - typically 7-30 days retention
In scoped applications, log entries are tagged with the application scope for easier filtering
Messages longer than 8192 characters are truncated without warning or error indication

Parameters

Name	Type	Required	Description
message	string	Yes	The log message to write. Supports substitution tokens like {0}, {1}, etc. that will be replaced with values from the parameters array. Maximum length is 8192 characters before truncation.
parameters	any	No	Variable number of arguments to substitute into the message string. Values are converted to strings using JavaScript's toString() method. Objects are serialized as JSON when possible.

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 logging with message substitutionbasic

// Log user actions with contextual information
var gr = new GlideRecord('incident');
if (gr.get('INC0000123')) {
    var oldState = gr.getValue('state');
    gr.setValue('state', '6'); // Resolved
    gr.update();
    
    // Log the state change with user context
    gs.info('Incident {0} resolved by {1}, previous state: {2}', 
           gr.getValue('number'), 
           gs.getUserName(), 
           oldState);
    
    // Multiple parameter types work fine
    gs.info('Resolution time: {0} hours for priority {1} incident', 
           gs.dateDiff(gr.opened_at, gr.resolved_at, true) / 3600000,
           gr.getValue('priority'));
}

This demonstrates the core pattern: log meaningful business events with enough context to be useful later. The substitution parameters are automatically converted to strings and inserted into the message.

Logging integration events with object dataintermediate

// REST endpoint processing with structured logging
function processWebhookData(requestBody) {
    try {
        var payload = JSON.parse(requestBody);
        var ticketNum = payload.ticket_number;
        
        // Log the inbound request with sanitized data
        gs.info('Webhook received for ticket {0}, status: {1}, source: {2}',
               ticketNum,
               payload.status,
               payload.source_system);
        
        var gr = new GlideRecord('incident');
        gr.addQuery('number', ticketNum);
        gr.query();
        
        if (gr.next()) {
            gr.setValue('work_notes', 'Updated via webhook: ' + payload.notes);
            gr.update();
            gs.info('Successfully updated incident {0} via webhook', ticketNum);
        } else {
            gs.info('Webhook target not found: {0}', ticketNum);
        }
    } catch (e) {
        gs.error('Webhook processing failed: {0}', e.message);
    }
}

Production integration pattern showing INFO level for successful operations and ERROR level for failures. Notice how object properties are accessed individually rather than logging the entire object.

The classic mistake - logging sensitive dataadvanced

// WRONG - Don't do this
function authenticateUser(username, password, apiKey) {
    gs.info('Login attempt - user: {0}, password: {1}, key: {2}',
           username, password, apiKey);
    // This logs sensitive data in plain text!
}

// RIGHT - Log events without sensitive details
function authenticateUser(username, password, apiKey) {
    var startTime = new GlideDateTime();
    var authResult = validateCredentials(username, password, apiKey);
    var duration = gs.dateDiff(startTime, new GlideDateTime());
    
    if (authResult.success) {
        gs.info('User {0} authenticated successfully, duration: {1}ms',
               username, duration);
    } else {
        gs.info('Authentication failed for user {0}, reason: {1}',
               username, authResult.errorCode);
    }
}

The wrong approach logs passwords and API keys in plain text. The corrected version logs the authentication outcome and performance metrics without exposing sensitive data - exactly what you need for security auditing.

Gotchas

Unused substitution tokens like {5} remain as literal text in the log message if no corresponding parameter is provided.

Extra parameters beyond the highest token index are silently ignored - gs.info('Hello {0}', 'world', 'extra') only uses 'world'.

Complex objects get serialized as JSON when possible, but circular references cause fallback to '[object Object]' string.

Messages exceeding 8192 characters are truncated without any indication that truncation occurred.

The method works in client-side scripts but the logs appear in different locations and may not be visible in standard System Logs.

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