Governance on Script Logging in NetSuite

Introduction

NetSuite imposes strict governance limits on script logging to prevent excessive storage and maintain performance across accounts sharing the same database instance. Logging is an essential debugging and monitoring tool, but if overused, it can affect system stability and data storage.

To keep things efficient, NetSuite automatically monitors logging behavior and enforces restrictions when thresholds are exceeded.

SuiteScript Logging Governance Model

NetSuite’s logging governance model is designed to balance visibility with performance:

If your script exceeds the allowed logging threshold, NetSuite automatically adjusts the log level to prevent excessive usage — keeping the script running but reducing unnecessary logging output.

Automatic Log Level Adjustments

NetSuite continuously monitors script logging volume.
If a single script logs excessively — for example, making 70,000 log.debug() calls within 20 minutes — the system automatically raises its log level to a higher threshold such as Audit.

Example scenario:

• Original script log level: Debug
• Script floods logs with repetitive log.debug() entries
• NetSuite raises log level → Audit
• Result: Script continues running, but debug messages no longer appear in the log

You can view this new log level in the Log Level field on the script’s Deployment page.

This automatic control prevents excessive debug logging while maintaining script execution.

N/log Module Overview

The N/log module allows developers to record execution information at varying log levels:

Tip: Use Audit or Error for production scripts and reserve Debug for sandbox testing.

Script Execution Log Storage and Retention

All script execution logs in NetSuite are stored for a limited period — typically 30 days — and can be accessed via multiple interfaces:

⚠️ Important:
If you require long-term log retention, create a custom record or external logging mechanism (via RESTlet or middleware) to store logs beyond the 30-day limit.

Script Owner Notifications

When excessive logging is detected:

• The script owner receives an email notification.
• A log entry is added to the script’s Execution Log, indicating the automatic log level change.
• The new level (e.g., from Debug → Audit) is visible on the Script Deployment page.

These notifications help developers quickly identify and fix overly verbose logging patterns before they impact account-level performance.

Best Practices for Efficient Script Logging

✅ Use Logging Strategically:
Reserve log.debug() for development; rely on log.audit() or log.error() in production.

✅ Implement Conditional Logging:
Wrap logs in conditions (e.g., if (debugMode) log.debug(...)) so you can toggle verbosity easily.

✅ Aggregate Messages:
Combine related details into a single log entry instead of multiple small ones.

✅ Monitor Log Volumes:
Regularly check the Execution Log subtab to identify scripts that produce excessive logs.

✅ Purge or Archive Logs:
Implement a scheduled process to periodically export and clear old logs from custom records.

✅ Avoid Logging Inside Loops:
Logging within loops (especially during search.run().each() or for iterations) is a common cause of performance issues.

Sample Logging Pattern

Here’s a controlled example of safe, efficient logging:

/**
 * Example: Controlled Logging in SuiteScript 2.x
 */
define(['N/log', 'N/runtime'], (log, runtime) => {
    function execute(context) {
        const script = runtime.getCurrentScript();
        log.audit('Script Started', `Remaining Usage: ${script.getRemainingUsage()}`);

        try {
            // Business logic
            log.debug('Processing Record', { id: 12345, type: 'invoice' });
        } catch (e) {
            log.error('Error Processing', e.message);
        }

        log.audit('Script Completed', `Remaining Usage: ${script.getRemainingUsage()}`);
    }
    return { execute };
});

This pattern uses Audit and Error logs for operational visibility, and Debug only when troubleshooting.

Key Takeaways

• A company can generate up to 100,000 log calls per hour across all scripts.
• Excessive logging triggers automatic log level elevation to limit system impact.
• Logs are retained for 30 days (user-generated) or 60 days (system errors).
• Use the N/log module responsibly and monitor logs through the Execution Log subtab or Server Script Log search.
• For long-term tracking, use custom records or external integrations for log archiving.

Related Reading

• SuiteScript Governance and Usage Limits
• Script Type Usage Unit Limits