NetSuite Script Time Limits: SSS_TIME_LIMIT_EXCEEDED by Script Type and Map/Reduce Stage
Understand NetSuite execution-time limits for SuiteScript, map/reduce stages, and plug-ins. Learn why SSS_TIME_LIMIT_EXCEEDED can occur even when a script has usage units remaining.
NetSuite script time limits determine how long a script, plug-in, or map/reduce stage can run before NetSuite stops it with SSS_TIME_LIMIT_EXCEEDED. The applicable ceiling depends on the execution type: many entries are limited to 300 seconds, while scheduled scripts, several installation-related types, and some map/reduce stages have 3,600-second limits. These elapsed-time limits are separate from governance usage units.
TL;DR: SSS_TIME_LIMIT_EXCEEDED means an execution exceeded the elapsed-time limit for its script type, plug-in type, or map/reduce stage. Remaining governance units do not prevent this error. Map/reduce limits are stage-specific: input and summarize have 3,600 seconds, map has 300 seconds, and reduce has 900 seconds.
Key takeaways
- NetSuite throws
SSS_TIME_LIMIT_EXCEEDEDand stops an execution when it exceeds the time limit for its script type, plug-in type, or map/reduce stage. - Elapsed time and governance usage units are separate constraints. A script can have units remaining when it reaches its time limit.
- A 300-second limit is common, but it is not universal. Several script and plug-in types have shorter or longer limits.
- Map/reduce does not have one overall duration limit for a deployment instance; the input, map, reduce, and summarize stages are regulated separately.
- Scripts executed in the SuiteScript 2.1 Debugger have a 300-second time limit, and scripts being debugged have a 1,000-unit usage limit.
What does SSS_TIME_LIMIT_EXCEEDED mean in NetSuite?
SSS_TIME_LIMIT_EXCEEDED means that a server script or plug-in ran longer than the elapsed-time limit assigned to that execution type. When the limit is exceeded, NetSuite stops the execution.
Start by identifying the exact execution type. A user event, RESTlet, Suitelet, scheduled script, core plug-in, and map/reduce stage do not necessarily receive the same amount of time. Map/reduce stages within the same deployment can also have different ceilings.
The official NetSuite execution-time limits provide the underlying values used here. The limits are measured in seconds and apply to a single execution of the applicable script, plug-in, or stage.
Why can SSS_TIME_LIMIT_EXCEEDED occur with usage units remaining?
A time limit governs elapsed execution time. Usage units are a separate form of governance metering. Script.getRemainingUsage() reports the usage units remaining for a script; it does not report how many seconds remain before the execution-time ceiling.
That distinction explains why an execution can fail with SSS_TIME_LIMIT_EXCEEDED while its usage-unit reading appears healthy. The source material identifies several contributors to elapsed time that may not exhaust the usage-unit allowance:
- Many record operations
- Many transactions involving the same records, such as items or lot numbers
- Triggered user event scripts or workflows
- Database queries or updates that collectively take a long time
Client scripts are metered on a per-script basis. Where a form-level client script and a record-level client script are deployed to a record, each can total 1,000 usage units. The SuiteScript 2.1 Custom Tool and Event Subscriber script types have 1,000 units per execution, while bundle installation scripts have 10,000 units per execution. Those unit allowances remain separate from the time limits below.
For governance context, see SuiteScript usage-unit limits by script type and SuiteScript governance limits and performance.
SuiteScript execution-time limits by script type
Many listed script types have a 300-second limit. Scheduled scripts, bundle installation scripts, the SuiteScript 2.1 Event Subscriber Script Type, and the SuiteScript 2.1 SDF Installation Script Type are listed with 3,600 seconds. Use the exact execution type instead of assuming that every script in an account has the same ceiling.
| Script type or stage | Time limit (seconds) |
|---|---|
| Bundle Installation Scripts (SuiteScript 1.0) / SuiteScript 2.1 Bundle Installation Script Type | 3,600 |
| Client Scripts (SuiteScript 1.0) / SuiteScript 2.1 Client Script Type | 300 |
| Custom record action | 300 |
| SuiteScript 2.1 Custom Tool Script Type | 300 |
| SuiteScript 2.1 Event Subscriber Script Type | 3,600 |
| Map/reduce input stage | 3,600 |
| Map/reduce map stage | 300 |
| Map/reduce reduce stage | 900 |
| Map/reduce summarize stage | 3,600 |
| Mass Update Scripts (SuiteScript 1.0) / SuiteScript 2.1 Mass Update Script Type | 300 |
| Portlet Scripts (SuiteScript 1.0) / SuiteScript 2.1 Portlet Script Type | 300 |
| RESTlets (SuiteScript 1.0) / SuiteScript 2.1 RESTlet Script Type | 300 |
| SuiteScript 2.1 SDF Installation Script Type | 3,600 |
| Single-page application (SPA) | 300 |
| Scheduled Scripts (SuiteScript 1.0) / SuiteScript 2.1 Scheduled Script Type | 3,600 |
| Suitelets (SuiteScript 1.0) / SuiteScript 2.1 Suitelet Script Type | 300 |
| SuiteScript Server Pages (SSP) application | 300 |
| User Event Scripts (SuiteScript 1.0) / SuiteScript 2.1 User Event Script Type | 300 |
| Workflow Action Scripts (SuiteScript 1.0) / SuiteScript 2.1 Workflow Action Script Type | 300 |
The 3,600-second Event Subscriber entry can be reviewed alongside the SuiteScript 2.1 Event Subscriber setup and deployment sequence.
How do map/reduce time limits apply to each stage?
NetSuite does not impose one overall duration limit on the full map/reduce deployment instance. Instead, isolated components of the deployment are regulated separately, including usage units used by a single method invocation. For a time-limit investigation, compare the failure with the limit for the relevant input, map, reduce, or summarize stage.
| Map/reduce stage | Time limit (seconds) | Troubleshooting meaning |
|---|---|---|
| Map/reduce input stage | 3,600 | Compare input-stage work with the 3,600-second limit. |
| Map/reduce map stage | 300 | Compare map-stage work with the 300-second limit. |
| Map/reduce reduce stage | 900 | Compare reduce-stage work with the 900-second limit. |
| Map/reduce summarize stage | 3,600 | Compare summarize-stage work with the 3,600-second limit. |
Do not apply an assumed 3,600-second ceiling to every map/reduce failure. Input and summarize have 3,600 seconds, map has 300 seconds, and reduce has 900 seconds.
Core and custom plug-in execution-time limits
Core plug-ins do not share one universal limit. The listed range runs from 30 seconds for Custom GL Lines Plug-in to 3,600 seconds for Financial Institution Connectivity Plug-in. Tax Engine has a 60-second limit, while the listed parser plug-ins have 1,800 seconds.
| Core plug-in type | Time limit (seconds) |
|---|---|
| Adjusted Consolidated Rates | 300 |
| Bank Connectivity Plug-in | 300 |
| Bank Statement Parser Plug-in | 1,800 |
| Custom GL Lines Plug-in | 30 |
| Dataset Builder Plug-in | 300 |
| Email Capture Plug-in | 300 |
| Financial Institution Connectivity Plug-in | 3,600 |
| Financial Institution Parser Plug-in | 1,800 |
| Payment Processing | 300 |
| Platform Extension | 300 |
| Promotions | 300 |
| Revenue Management | 300 |
| Shipping Partners | 300 |
| Tax Engine | 60 |
| Workbook Builder Plug-in | 300 |
The two documented custom plug-in entries both have 3,600-second limits.
| Custom plug-in type | Time limit (seconds) |
|---|---|
| Plug-in Type | 3,600 |
| Plug-in Type Implementation | 3,600 |
Do not transfer the custom plug-in value to a core plug-in implementation. The correct limit depends on the specific plug-in type.
What is the SuiteScript Debugger time limit?
Scripts executed in the SuiteScript 2.1 Debugger have a 300-second, or five-minute, time limit. Scripts being debugged also have a 1,000-unit usage limit. For example, a scheduled script that is permitted 10,000 units during normal NetSuite execution can encounter a usage-limit error in the Debugger if a 2,000-unit execution reaches the Debugger's 1,000-unit limit.
Additional restrictions apply while debugging SuiteScript 1.0, 2.0, and 2.1 scripts:
- Only one script can be debugged at a time. If the same debugging session is opened in multiple browser windows, the same script and session appear in both.
- You can debug only your own scripts in your current login session.
- 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 debugger environments have idle timeouts. For SuiteScript 1.0 and 2.0, the stated idle limit is two minutes; without user action during that period, the session ends.
A script that succeeds normally but fails during debugging may be encountering the Debugger's separate time or usage limit. See the SuiteScript Debugger tools guide for version-specific debugging context.
How should you investigate SSS_TIME_LIMIT_EXCEEDED?
Treat the error as an elapsed-time failure first, rather than assuming it is a usage-unit failure.
- Identify the exact execution type. Determine whether the failure occurred in a user event, RESTlet, Suitelet, scheduled script, plug-in, or another listed type.
- For map/reduce, identify the stage. Input and summarize have 3,600 seconds, map has 300 seconds, and reduce has 900 seconds.
- Compare the execution with the correct table entry. Do not use the common 300-second value as a default for types that explicitly have shorter or longer limits.
- Review remaining usage separately. Use
Script.getRemainingUsage()to evaluate governance headroom, not as proof that execution time remained. - Review elapsed-time contributors. Check for many record operations, repeated transactions involving the same records, triggered user events or workflows, and cumulative database queries or updates.
- Account for debugger restrictions. During SuiteScript 2.1 debugging, compare the execution with the 300-second time limit and 1,000-unit usage limit.
This sequence separates the applicable time ceiling from the separate question of usage-unit consumption.
Practical response to SSS_TIME_LIMIT_EXCEEDED
Focus the review on the work performed by the failing execution. The supplied material identifies record operations, repeated transaction processing for the same records, triggered automation, and cumulative database work as possible contributors to elapsed time. Reducing duplicate work or narrowing the records processed by an execution can reduce elapsed time while preserving a separate review of governance usage.
For map/reduce, assess work against the limit for the failing stage: 300 seconds for map, 900 seconds for reduce, and 3,600 seconds for input or summarize. Test normal execution separately from debugger execution because the Debugger has its own time and usage limits.
General development guidance is available in SuiteScript development best practices.
FAQ
Which script types and map/reduce stages have a 3,600-second execution-time limit?
The 3,600-second entries are Bundle Installation Scripts (SuiteScript 1.0) / SuiteScript 2.1 Bundle Installation Script Type, SuiteScript 2.1 Event Subscriber Script Type, map/reduce input stage, map/reduce summarize stage, SuiteScript 2.1 SDF Installation Script Type, and Scheduled Scripts (SuiteScript 1.0) / SuiteScript 2.1 Scheduled Script Type.
Can a script hit SSS_TIME_LIMIT_EXCEEDED with usage units remaining?
Yes. Time and usage units are separate constraints. Record operations, repeated transactions involving the same records, triggered user events or workflows, and cumulative database work can consume elapsed time without exhausting the usage-unit allowance.
What are the map/reduce execution-time limits?
The input stage has 3,600 seconds, the map stage has 300 seconds, the reduce stage has 900 seconds, and the summarize stage has 3,600 seconds. There is no single overall duration limit imposed on the full map/reduce deployment instance.
Do core and custom plug-ins have the same time limit?
No. Core plug-ins range from 30 seconds for Custom GL Lines Plug-in to 3,600 seconds for Financial Institution Connectivity Plug-in. The documented custom entries, Plug-in Type and Plug-in Type Implementation, each have 3,600 seconds.
What limits apply in the SuiteScript 2.1 Debugger?
Scripts executed in the SuiteScript 2.1 Debugger have a 300-second time limit. Scripts being debugged have a separate 1,000-unit usage limit. Only one script can be debugged at a time, and you can debug only your own scripts in your current login session.