NetSuite Script Time Limits and Debugger Rules

NetSuite assigns execution-time limits to script types and plug-in types. When a limit is exceeded, NetSuite throws SSS_TIME_LIMIT_EXCEEDED and stops script execution. The applicable limit depends on the script, plug-in, or map/reduce stage. Debugging also has separate time, usage-unit, session, and logging restrictions that can differ from normal execution.

What happens when a script exceeds its time limit?

Each server script type and plug-in type has a limit on the time it can run in a single execution. If it exceeds that limit, NetSuite throws SSS_TIME_LIMIT_EXCEEDED and script execution stops.

Time limits should be considered alongside usage-unit limits, but they are not the same constraint. Oracle notes that a script can run for a long time without displaying SSS_TIME_LIMIT_EXCEEDED in several situations:

• It performs many record operations without exceeding its usage-unit limit.
• It processes many transactions for the same records, such as items or lot numbers, without exceeding its usage-unit limit.
• It causes many user event scripts or workflows to execute.
• Its database queries or updates collectively take a long time to complete.

That distinction matters when reviewing a slow execution. Usage-unit consumption alone does not describe all of the work that may contribute to elapsed execution time. The source material also provides Script Type Usage Unit Limits, including the Script.getRemainingUsage() method for checking remaining usage units for a script.

Which script types have each execution-time limit?

The following limits are measured in seconds. They are the limits listed for each script type or map/reduce stage.

Map/reduce needs particular care when interpreting this table. The usage-unit material says there is no limit imposed on the full duration of a map/reduce script deployment instance. Instead, isolated components of the deployment, including usage units used by a single method invocation, are regulated. The time limits above identify the limits for the input, map, reduce, and summarize stages.

Which core and custom plug-ins have time limits?

Core plug-ins do not share one universal limit. Their listed limits range from 30 seconds for Custom GL Lines to 3,600 seconds for Financial Institution Connectivity.

The source lists the following limits for custom plug-ins:

For teams reviewing a mixed script and plug-in estate, the tables provide the relevant starting point: a 300-second limit is common, but it is not universal. Custom GL Lines and Tax Engine have shorter listed limits, while several installation, scheduled, event-subscriber, and financial-institution entries have 3,600-second limits.

How do time limits relate to usage-unit limits?

A time limit governs how long the execution can run. Usage units are a separate form of metering. The supplied usage-unit material identifies different total allowances by script type and notes that Script.getRemainingUsage() returns the usage units remaining for a particular script.

For example, the usage-unit source says client scripts are metered on a per-script basis. If an account has a form-level client script and a record-level client script deployed to a record, each can total 1,000 usage units; those units are not shared by all client scripts associated with that form or record. The same material lists 1,000 usage units per execution for the SuiteScript 2.1 Custom Tool and Event Subscriber script types, and 10,000 units per execution for bundle installation scripts.

The time-limit source specifically warns against using usage-unit status as the only indicator of a lengthy execution. Record work, transactions involving the same records, triggered user events or workflows, and cumulative database work can all correspond with a long-running script even where the usage-unit limit has not been exceeded.

For additional usage-unit and governance context, see SuiteScript Usage Unit Limits by Script Type Guide and SuiteScript Governance Limits and Performance in NetSuite.

What restrictions apply in the SuiteScript Debugger?

Scripts executed in the SuiteScript 2.1 Debugger have a 300-second, or five-minute, time limit. Oracle separately documents metering and permission restrictions that apply to all SuiteScript 1.0, 2.0, and 2.1 script types being debugged:

• Only one script can be debugged at a time. If multiple scripts are debugged simultaneously, such as from two browser windows, the same script/debugging session appears in both windows.
• You can debug only your own scripts in your current login session.
• Scripts being debugged have a 1,000-unit usage limit. The source highlights scheduled scripts as an example: although they are permitted 10,000 units when running in NetSuite, the Debugger throws a usage-limit error if a 2,000-unit scheduled script reaches 1,000 units while being stepped through or executed.
• Email error notification is disabled for scripts being debugged.
• For SuiteScript 1.0 and 2.0, execution-log details appear on the Debugger's Execution Log subtab rather than the Script Deployment execution log. For SuiteScript 2.1, execution-log details appear on the Console tab in the Chrome DevTools debugging window.

Both the SuiteScript Debugger and the 2.1 Script Debugger have idle timeouts. For SuiteScript 1.0 and 2.0 scripts in the debugger, the stated idle limit is two minutes: if no user action occurs during that period, the debug session ends.

Who This Affects

• SuiteScript developers: Review both the time limit for the selected script type and the separate usage-unit allowance for that type.
• Map/reduce developers: Apply the time-limit table at the stage level and distinguish those stage limits from the duration of the overall deployment instance.
• Plug-in developers: Check the specific core or custom plug-in entry rather than assuming the 300-second value applies to every plug-in.
• Debuggers of SuiteScript code: Account for the 1,000-unit debug limit, the single-script restriction, session ownership requirement, logging location, and idle timeout rules.
• Teams investigating slow execution: Include record operations, repeated work on the same records, triggered user events or workflows, and cumulative database operations in the review—not only usage-unit consumption.

Key Takeaways

• A script or plug-in that exceeds its listed execution-time limit throws SSS_TIME_LIMIT_EXCEEDED and stops executing.
• Listed limits range from 30 seconds for Custom GL Lines to 3,600 seconds for several script and plug-in types.
• Map/reduce has stage-specific time limits; the supplied usage-unit documentation says the overall deployment instance has no full-duration limit.
• A long-running script may not display SSS_TIME_LIMIT_EXCEEDED merely because it performs extensive record, transaction, workflow, or database work without exceeding its usage-unit limit.
• The SuiteScript 2.1 Debugger has a 300-second execution-time limit, while debugger metering also imposes a 1,000-unit limit on scripts being debugged.

For related implementation references, see Error Handling for SuiteScript Sublist Values, HTTP Request Error Management in NetSuite SuiteScript 2.x, and Script Object Members in SuiteScript for Developers.