# Fix NetSuite SSS_USAGE_LIMIT_EXCEEDED Error > Source: https://netray.co/erp-help/netsuite-sss-usage-limit-exceeded-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer SSS_USAGE_LIMIT_EXCEEDED fires when a SuiteScript execution consumes all the governance units (usage points) allotted to its script type before it finishes. Fix it by checking runtime.getCurrentScript().getRemainingUsage() before expensive calls, yielding or rescheduling in Scheduled scripts, and moving heavy record-count work into Map/Reduce, which yields automatically across stages. ## Kind error ## System netsuite ## Erp Oracle NetSuite ## Module SuiteScript / Script Governance ## Query SSS_USAGE_LIMIT_EXCEEDED NetSuite error ## Alternate Queries - You have exceeded the usage limit NetSuite - NetSuite script governance limit exceeded fix - SuiteScript usage units exceeded error - how to fix SSS_USAGE_LIMIT_EXCEEDED ## Applies To NetSuite SuiteScript 1.0 and 2.x, all script types (User Event, Scheduled, Client, Suitelet, RESTlet, Map/Reduce), all NetSuite account tiers ## Steps ### How to fix SSS_USAGE_LIMIT_EXCEEDED **Items:** - Identify which script and deployment threw the error from Customization > Scripting > Script Execution Log or the Scheduled Script Status page. - Check the governance cost of the script type: User Event 1000 units, Scheduled Script 10000 units, Client Script 1000, Suitelet 1000, RESTlet 5000, Map/Reduce yields per stage automatically. - Add runtime.getCurrentScript().getRemainingUsage() checks before expensive operations (search.create().run(), record.save(), nested N/search calls) and branch to reschedule or stop. - For Scheduled Scripts nearing the limit, call runtime.getCurrentScript().reschedule(params) or convert the script to Map/Reduce so NetSuite handles yielding between stages automatically. - Reduce per-record cost: replace record.load() plus record.save() pairs with record.submitFields() when only a few fields change, since submitFields costs far fewer governance units. - Batch search results instead of looping with search.run().each() calling nested searches inside the loop; consolidate into a single joined saved search. - In Map/Reduce, move heavy lookups out of the map/reduce stage into getInputData() where possible, and keep reduce stage logic to per-key work only. - Re-run and confirm via the script log that usage remaining stays above zero through completion. ## Sections ### Why this happens **Body:** Every SuiteScript execution runs inside a governance budget measured in units, not seconds. NetSuite assigns each script type a fixed unit allowance and charges a fixed number of units per API call: record.save() costs 20 units, search.create().run() costs 10, an N/https call can cost 10-100 depending on the type. SSS_USAGE_LIMIT_EXCEEDED means the script tried to spend more units than it had left, and NetSuite killed the execution mid-run. This is different from a timeout. A script can be well within any wall-clock limit and still fail on governance because it processed too many records or made too many nested calls per record. The error is most common in User Event scripts on high-volume transaction types (sales order, item fulfillment) and in Scheduled Scripts written before Map/Reduce existed. ### Diagnose the real cost driver **Body:** Open Customization > Scripting > Script Deployments, find the deployment, and check the execution log for the line where usage hit zero. The log entry right before the SSS_USAGE_LIMIT_EXCEEDED line usually shows the last successful API call and its cost, which tells you exactly which loop or function is the offender. A common pattern is a beforeSubmit or afterSubmit User Event that calls record.load() on related records inside a for loop over line items. On a sales order with 200 lines, that alone can burn well over 4000 units before any business logic runs. Count your API calls per line item and multiply by expected line count to estimate worst-case usage. ### Fixes ranked by effort **Body:** Cheapest fix: swap record.load() plus a field set plus record.save() for record.submitFields(), which is priced far lower because it does not reload the whole record. This alone resolves most User Event governance errors on transaction saves. Structural fix: convert long-running Scheduled Scripts to Map/Reduce (Customization > Scripting > Scripts > New, type Map/Reduce). NetSuite yields and resumes each stage automatically, so a job that used to fail on 10000 units can process tens of thousands of records across many queued executions without manual usage management. **Code:** - // Cheap update instead of load+save record.submitFields({ type: record.Type.SALES_ORDER, id: soId, values: { custbody_status: 'processed' } }); ### Prevent recurrence **Body:** Add a guard at the top of any loop: if (runtime.getCurrentScript().getRemainingUsage() < 50) { break; } combined with a reschedule call for Scheduled Scripts, or a checkpoint for Map/Reduce, so the script degrades gracefully instead of throwing. For User Event scripts on high-volume records, move non-critical logic (notifications, logging, secondary record updates) out of the synchronous User Event and into a Scheduled Script or Map/Reduce triggered by a saved search, so the save transaction itself stays cheap and fast. ## Pitfalls - Assuming SuiteScript 2.x scripts have unlimited usage - they still have a per-execution cap, they just yield automatically in Map/Reduce, not in User Event or Client scripts. - Wrapping expensive N/search calls inside a loop instead of doing one search with joins and reading columns from the result. - Calling record.save() to update one field when record.submitFields() would cost a fraction of the units. - Forgetting that workflow actions (Set Field Value via script, custom actions) also draw from the triggering script's governance budget. - Not checking getRemainingUsage() until after the expensive call already failed. ## Ai Angle ERPray, grounded on your SuiteScript deployment history and execution logs, can trace a recurring SSS_USAGE_LIMIT_EXCEEDED back to the specific script, deployment, and line of business logic in seconds instead of you paging through the Script Execution Log manually. Ask it why the sales order User Event failed on a given order and it correlates the log entry, the script's governance cost pattern, and prior similar failures, then suggests the submitFields or Map/Reduce refactor that matches how your account's scripts are actually structured. ## Faq ### Does upgrading to SuiteScript 2.1 remove the usage limit? **Answer:** No. 2.1 scripts still have governance limits per script type. Map/Reduce scripts get automatic yielding between stages, which is why they rarely hit this error, but User Event, Client, Suitelet, and RESTlet scripts still have a fixed unit budget per execution. ### What is the governance cost of a workflow action script? **Answer:** It draws from the same budget as the record event that triggered the workflow, typically the User Event governance pool, so heavy logic in a Set Field Value via script action can still throw SSS_USAGE_LIMIT_EXCEEDED even though you did not write a standalone script. ### Can I raise the usage limit for a script? **Answer:** You cannot raise the hard per-execution limit, but Scheduled Scripts and Map/Reduce scripts can reschedule themselves to continue in a new execution, effectively processing unlimited total records across multiple queued runs. ### Why does the same script fail only on large orders? **Answer:** Because usage cost scales with the number of API calls, and most failing scripts loop over line items. A 20-line order might pass comfortably while a 300-line order exhausts the budget partway through the loop. ## Search terms SSS_USAGE_LIMIT_EXCEEDED, NetSuite governance limit, SuiteScript usage units, NetSuite script governance, fix usage limit exceeded netsuite, NetSuite Map/Reduce yield, record.submitFields governance cost, NetSuite getRemainingUsage, SuiteScript performance, NetSuite scheduled script error --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json