Log a message to the system log

ServiceNow's logging methods write to the system log table (syslog) with different severity levels that control visibility and retention. Most developers use gs.log() for everything, but the platform treats debug, info, warn, and error messages differently — debug messages are filtered by default in production, while error messages trigger monitoring alerts. The biggest mistake is logging inside loops over query results, which creates thousands of identical log entries that overwhelm the system and make real issues impossible to find.

When to use this

• When debugging complex Business Rules or Script Includes that process records with multiple state transitions
• When tracking integration failures or unexpected API responses that need administrator attention
• When validating business rule execution in Scheduled Jobs that run unattended
• When creating audit trails for high-value record changes that bypass standard audit tables

When NOT to use this

• Don't log inside while(gr.next()) loops — log the count or summary instead
• Don't use this for user-facing messages — use gs.addInfoMessage() or gs.addErrorMessage() instead
• Don't log in Client Scripts — system logs are server-side only, use browser console instead
• Don't log sensitive data like passwords or API keys — system logs are readable by system administrators

Key behaviors and gotchas

• gs.log() writes debug level messages — filtered out by default in production instances
• gs.info() is always visible and should be your default for application flow tracking
• gs.warn() and gs.error() can trigger monitoring alerts depending on instance configuration
• The source parameter is optional but critical for filtering logs — use your script name or table name
• Log messages are truncated at 4000 characters — split long messages or use JSON.stringify() for objects
• System logs respect domain separation — messages only visible to users in the same domain