SuiteScript Usage Unit Limits by Script Type and Execution Scope
SuiteScript usage unit limits range from 1,000 to 10,000 units for most script types, but the number is only part of the rule. This reference explains whether governance applies per script, execution, record, workflow state, API and script level, or Map/Reduce component.
SuiteScript usage unit limits are useful only when read with the execution scope that shares the allowance. A 1,000-unit ceiling can apply to one client script, all actions in a Suitelet, one workflow state, or a mass-update record or script execution. Scheduled scripts, RESTlets, Map/Reduce, and the debugger follow different published models.
TL;DR: Client scripts receive 1,000 units per script. Scheduled scripts combine all actions within one execution under a 10,000-unit limit. RESTlets have a 5,000-unit limit tracked at API and script levels. Map/Reduce has no full-deployment-instance ceiling; isolated components are regulated.
Key takeaways
- Read the script type and metering scope together; the number alone does not describe what shares the allowance.
- Client scripts are metered separately at 1,000 units per script, not as a combined form or record pool.
- Scheduled scripts have 10,000 units for all actions within one scheduled script execution.
- Workflow action scripts share 1,000 units within one workflow state, while Suitelets combine their actions under a 1,000-unit limit.
runtime.getCurrentScript().getRemainingUsage()reports the units left for the currently executing script and has no governance cost.
What do SuiteScript governance limits measure?
SuiteScript 1.0 and 2.1 usage-unit ceilings vary by script type and, in several cases, by execution scope. The scope determines whether related work is charged against one allowance or against separately metered scripts. For example, client scripts are metered per script, while all actions in a scheduled script are combined.
Usage units are separate from applicable execution-time restrictions. Use the NetSuite script time limits and debugger rules reference when evaluating that separate dimension, and see the SuiteScript governance and performance overview for wider governance context.
For design reviews, start by identifying the script type, then identify the documented boundary that shares its allowance. The table below consolidates the published maximum allowable usage units.
What are the SuiteScript usage unit limits by script type?
| Script type | Maximum usage units | Documented scope or note |
|---|---|---|
| Bundle Installation Script | 10,000 | Per execution |
| Client Script | 1,000 | Metered per script |
| Custom Tool Script | 1,000 | Per execution of the tool |
| Event Subscriber Script | 1,000 | Per execution of the script |
| Map/Reduce Script | — | No limit is imposed on the full duration of a deployment instance; isolated components are regulated |
| Mass Update Script | 1,000 | Per record or execution of the script |
| Portlet Script | 1,000 | — |
| RESTlet | 5,000 | Governance tracks usage units at the API level and script level |
| Scheduled Script | 10,000 | All actions within one scheduled script combined |
| SDF Installation Script | 10,000 | Per execution |
| Suitelet | 1,000 | All actions within one Suitelet combined |
| User Event Script | 1,000 | — |
| Workflow Action Script | 1,000 | All actions within one workflow state combined |
| Core Plug-in | Varies | Default is 10,000 where no more restrictive plug-in limit is defined |
| Custom Plug-in | 10,000 | Per plug-in |
| SSP Application Script | 1,000 | — |
| SuiteScript Debugger | 1,000 | A separate debugger usage-unit limit applies |
The table is a reference, not a substitute for scope analysis. Two script types can have the same numeric maximum while using different boundaries. Map/Reduce is the clearest exception: its published model regulates isolated components rather than assigning one aggregate ceiling to the full deployment instance.
Client scripts and scheduled scripts: different sharing rules
A Client Script has a 1,000-unit limit on a per-script basis. If a form has one form-level client script and a record-level client script deployed to a record associated with that form, each script can total 1,000 usage units. The published rule is separate metering, not a shared 1,000-unit pool for the form or record.
That distinction changes how teams investigate client-side governance. Review the usage of each attached or deployed client script independently. For related client-side implementation work, see how the SuiteScript commitLine method handles sublist operations, while retaining the per-script governance model.
Scheduled Scripts use a combined-action model. Within one scheduled script, all actions combined cannot exceed 10,000 usage units. The documented example of two record.transform(options) calls and one email.send(options) call consumes 24 to 40 units, depending on the record type used with record.transform(options). That total comes from the execution's 10,000-unit allowance.
For a scheduled script with potentially long execution times, NetSuite recommends considering Map/Reduce. SuiteScript 2.1 does not provide a method to set recovery points or yield to avoid exceeding scheduled-script governance. Map/Reduce has built-in yielding and can be submitted for processing in the same ways as a scheduled script.
Map/Reduce and RESTlet governance
Map/Reduce scripts are not available in SuiteScript 1.0. In SuiteScript 2.1, NetSuite does not impose a usage-unit limit on the full duration of a Map/Reduce deployment instance. Instead, it regulates isolated components, including usage consumed by a single method invocation. “No full-duration limit” therefore does not mean that governance does not apply.
The planning difference is straightforward: a scheduled script draws every governed action in one execution from its 10,000-unit allowance, while Map/Reduce processing is regulated at component level. That distinction is why a potentially long-running scheduled workload may be a candidate for Map/Reduce.
RESTlets have a 5,000-unit limit. Their governance tracks usage units at both the API level and the script level, which is distinct from the client-script per-script rule and scheduled-script combined-action rule. When diagnosing an integration, keep RESTlet governance separate from request-specific behavior; the HTTP request error management guide addresses that separate troubleshooting concern.
Suitelets, user events, and workflow actions
A Suitelet has a 1,000-unit limit, with all actions in that Suitelet combined. In the documented example, record.create(options) plus http.get(options) consumes 12 to 20 units, depending on the record type used for record.create(options).
NetSuite states that Suitelets should remain responsive to users regardless of the 1,000-unit ceiling; otherwise, user experience may be affected. The same responsiveness guidance applies to User Event Scripts, which also have a 1,000-unit limit.
Workflow Action Scripts, also called Custom Actions in SuiteFlow, have a 1,000-unit limit within one workflow state. All actions in that state contribute to the same allowance. If one custom action consumes 990 units, the consumption of other actions in that state must also be considered. Do not assign a separate 1,000-unit pool to every Custom Action.
Installation, plug-in, and debugger limits
Bundle Installation Scripts and SDF Installation Scripts each have a 10,000-unit limit per execution. A Bundle Installation Script can run during bundle installation, update, or uninstallation. If it fails, the applicable bundle operation stops, so its work should be assessed within the relevant execution rather than treated as a permanent bundle-wide allowance.
Other published 1,000-unit entries have their own scopes: Custom Tool Scripts are limited per execution of the tool, Event Subscriber Scripts per execution of the script, and Mass Update Scripts per record or execution of the script. For configuration and deployment context, see the SuiteScript 2.1 Event Subscriber setup guide.
A Custom Plug-in has 10,000 units per plug-in. A Core Plug-in varies, with a default of 10,000 where no more restrictive plug-in limit is defined. The SuiteScript Debugger has its own separate 1,000-usage-unit limit. Use the SuiteScript Debugger tools for SuiteScript 1.0, 2.0, and 2.1 guide for debugger-specific workflow.
How do you check remaining SuiteScript governance 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, 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());
This is member syntax rather than a complete functional script. It obtains the current script object and reports the units left in that execution; it does not change the script type's allowance or execution scope.
Interpret the result using the table above. In a Scheduled Script, it reflects what remains after combined actions consume the execution's 10,000 units. In a Client Script, it applies to that separately metered script. In a Suitelet, it reflects the allowance available to the actions combined within that Suitelet.
FAQ
Do these limits cover SuiteScript 1.0 and 2.1?
Yes. The reference consolidates published limits for SuiteScript 1.0 and 2.1 script types. Map/Reduce is not available in SuiteScript 1.0.
Does Map/Reduce have one deployment-wide usage-unit ceiling?
No. NetSuite does not impose a limit on the full duration of a Map/Reduce deployment instance. It regulates isolated components, including a single method invocation.
What is the Scheduled Script usage limit?
A Scheduled Script has 10,000 usage units, with all actions combined within one scheduled script execution.
Does checking remaining usage consume units?
No. Script.getRemainingUsage() has no governance cost and reports the units remaining for the currently executing script.