SuiteScript Usage Unit Limits by Script Type Guide

SuiteScript 1.0 and 2.1 usage-unit ceilings vary by script type and, in several cases, by execution scope. This reference lists each published maximum, explains client, workflow, RESTlet, scheduled, and Map/Reduce metering distinctions, and shows how Script.getRemainingUsage() reports the units left in the currently executing script.

What are the published usage-unit limits by script type?

The table below consolidates the maximum allowable usage units listed for SuiteScript 1.0 and 2.1 script types. A numeric limit is not always simply a per-deployment total: client scripts are measured per script, mass updates can be per record, and workflow actions share a state-level allowance.

Map/Reduce scripts are not available in SuiteScript 1.0. Their published rule differs from the numeric ceilings in the table: NetSuite does not impose a limit on the full duration of a Map/Reduce deployment instance, but regulates isolated components, including the usage units consumed by a single method invocation.

How do the execution scopes differ?

The limit number alone is not enough for planning. The documented metering scope determines whether related activity draws from one allowance or has separate allowances.

Client scripts are metered separately

Client scripts have a 1,000-unit limit on a per-script basis. If an account has one form-level client script attached to a form and one record-level client script deployed to a record associated with that form, each script can total 1,000 usage units. Usage units are not shared across all client scripts associated with the form or record.

That distinction matters when reviewing customizations attached at both levels: the published rule is separate metering for each script, not a combined 1,000-unit pool for the form or record.

Scheduled scripts combine all actions

Within one scheduled script, all actions combined cannot exceed 10,000 usage units. The documented example uses two record.transform(options) calls and one email.send(options) call. Together, those calls consume 24 to 40 units, depending on the record type used with record.transform(options), from the 10,000 units available.

For a scheduled script with potentially long execution times, NetSuite recommends considering a Map/Reduce script instead. SuiteScript 2.1 does not provide a method to set recovery points or yield to avoid exceeding scheduled-script governance. A Map/Reduce script has built-in yielding and can be submitted for processing in the same ways as a scheduled script.

Suitelets and user events should remain responsive

A Suitelet has a 1,000-unit limit, with all actions in that Suitelet combined. The published example of record.create(options) plus http.get(options) consumes 12 to 20 units, depending on the record type used for record.create(options), out of the 1,000-unit allowance.

NetSuite also states that Suitelets should be responsive to users regardless of the 1,000-unit limit; otherwise, user experience may be affected. The same responsiveness guidance applies to user event scripts, which also have a 1,000-unit limit.

Workflow actions share a state-level allowance

Workflow action scripts, also referred to as Custom Actions in SuiteFlow, have a 1,000-unit limit within one workflow state. All actions in that state combined cannot exceed the limit. For example, where a custom action consumes 990 units, the consumption of the other actions in the same state must also be considered.

RESTlets are tracked at two levels

RESTlets have a 5,000-unit limit. Their governance model tracks usage units at both the API level and the script level. This is a distinct metering description from the per-script client-script rule and the combined-action rules for scheduled scripts, Suitelets, and workflow states.

How can a script report its remaining units?

Script.getRemainingUsage() returns the number of units remaining, subject to governance limitations, for the currently executing script. It is supported by client and server scripts, is available from the N/runtime module, has no governance cost, and has been available since 2015.2.

var scriptObj = runtime.getCurrentScript();
log.debug('Remaining governance units: ' + scriptObj.getRemainingUsage());

The sample shows the member syntax rather than a complete functional script. Its value is that it reports the remaining units for the current execution; it does not change the limit assigned to the script type.

The SuiteScript Debugger has its own 1,000-usage-unit limit. This debugger limit should be distinguished from the script-type limits in the main table.

What should bundle installation script authors account for?

Bundle installation scripts have a 10,000-unit limit per execution and are specialized server scripts for processes in target accounts when a bundle is installed, updated, or uninstalled. Those processes can include setup, configuration, and data-management tasks that would otherwise be performed by account administrators.

A bundle can include a bundle installation script that runs automatically during installation, update, or uninstallation. The script can contain triggers for before install, after install, before update, after update, and after uninstallation. Unlike other SuiteScript types, it has no audience: it always executes using the Administrator role in the context of the bundle operation and has no event types.

Before a bundle installation script can be associated with a bundle, it needs a script record and at least one deployment. A bundle creator selects one of its deployments in Bundle Builder. If the script fails, the bundle installation, update, or uninstallation stops. The script can include its own error handling in addition to errors thrown by SuiteBundler and SuiteScript; when it throws an error, it returns an Installation Error code followed by the message defined by the script author.

Who This Affects

• Script authors working with the 1,000-unit limits for client scripts, Suitelets, user events, workflow actions, portlets, mass updates, custom tools, event subscribers, or SSP application scripts.
• Teams designing scheduled scripts whose combined actions may approach the 10,000-unit allowance.
• Teams using Map/Reduce, where the relevant governance consideration is regulated isolated components rather than the full deployment-instance duration.
• Bundle creators and script authors configuring bundle installation scripts, which run under the Administrator role and can stop the bundle operation if they fail.
• Developers using the SuiteScript Debugger, which has a separate 1,000-unit limit.

Where can you find related guidance?

For broader governance, API, logging, search-result, execution-time, RESTlet, and script-type details, consult the relevant NetSuite documentation for the specific script or plug-in. Core plug-ins require particular attention because 10,000 is only the default when no more restrictive plug-in limit is defined.

Related reading:

• SuiteScript Governance Limits and Performance in NetSuite
• HTTP Request Handling in SuiteScript 2.x: Parameters
• getField usage in SuiteScript 2.x
• Updating Records with record.submitFields
• Field Value Handling in Date/Time Scripts

Key Takeaways

• Published usage-unit limits range from 1,000 to 10,000 for most listed script types, while Map/Reduce is governed by isolated components rather than a full deployment-instance duration limit.
• The scope is material: client scripts are metered per script, scheduled scripts and Suitelets combine actions, and workflow actions share the allowance for a workflow state.
• Script.getRemainingUsage() reports the remaining units for the currently executing client or server script and has no governance cost.
• A potentially long-running scheduled script should be evaluated for Map/Reduce because SuiteScript 2.1 scheduled scripts do not provide recovery-point or yield methods, while Map/Reduce includes built-in yielding.
• Bundle installation scripts run as Administrator and a failure stops the associated installation, update, or uninstallation operation.