If you’ve hit SSS_USAGE_LIMIT_EXCEEDED, governance is already a real problem, not a theoretical one. Most explanations stop at “it’s a budget of units,” true but incomplete: it doesn’t explain why the same code fails as a User Event and runs fine as a Map/Reduce script. That’s the part worth knowing when picking a script type.
What governance actually measures
Baseline unit costs (SuiteScript 2.x)
|
Operation
|
Cost
|
|---|---|
|
record.load()
|
10
|
|
record.save()
|
20
|
|
search.run() (per page)
|
10
|
|
query.runSuiteQL()
|
10
|
|
record.submitFields()
|
10
|
|
Sending email
|
20
|
Costs vary a little by record type, custom records are cheaper than transactions, but these are close enough for planning. What changes script to script isn’t the operation’s cost. It’s the size of your budget.
query.runSuiteQL() costs the same 10 units as a page of N/search results but can do far more: grouping, subqueries, joins, or window functions that would otherwise take several stitched-together searches. One 10-unit query often beats three or four separate searches for a rollup or ranking report, and has no result cap with SuiteAnalytics Connect enabled (100,000 without it, still well beyond plain N/search).
Budget by script type
|
Script Type
|
Governance Limit
|
|---|---|
|
User Event
|
1,000 units
|
|
Suitelet
|
1,000 units
|
|
Client Script
|
1,000 units (tracked but generally unenforced)
|
|
RESTlet
|
5,000 units
|
|
Scheduled Script
|
10,000 units
|
|
Map/Reduce (getInputData)
|
10,000 units
|
|
Map/Reduce (map, per invocation)
|
1,000 units
|
|
Map/Reduce (reduce, per invocation)
|
5,000 units
|
|
Map/Reduce (summarize)
|
10,000 units
|
Here’s the trap: people often assume Map/Reduce succeeds because it has a much bigger budget. It doesn’t, not really. The map stage gets the same 1,000-unit allowance as a User Event or Suitelet; the difference is the budget applies per invocation, not per job. reduce gets more room, 5,000 units, since it’s expected to aggregate multiple records under one key.
The real advantage isn’t a larger bucket. It’s that NetSuite checkpoints the work, re-queues it automatically, and resumes when a bucket runs dry. Those limits get hit all the time; you just never notice, because the framework keeps moving.
Scheduled Scripts and RESTlets are the opposite: real budgets—10,000 and 5,000 units—but once those are gone, that’s it, no checkpointing, no resume. A Scheduled Script can run fine in sandbox for months on small test data, then fail in production once a client’s data grows; the code never changed, only the volume. If a RESTlet starts processing hundreds of records in one request, that work usually belongs in Map/Reduce instead.
Worked example: updating 500 records
Suitelet or User Event: 500 records × (10 to load + 20 to save) = 15,000 units against a 1,000-unit budget. You’ll run out after roughly 33 records.
Scheduled Script: Same 15,000 units, against a 10,000-unit budget. You’ll get through around 333 records before it dies, and without your own checkpointing logic, the rest won’t process.
Map/Reduce: Each record runs as its own invocation with its own 1,000-unit allowance. A load and save costs 30 units, and NetSuite keeps scheduling the remaining work automatically. Not a bigger budget, just checkpointing you didn’t have to write.
When governance failures actually happen
- A User Event firing on every save during a saved-search mass update.
- A Suitelet loading full records to render a list instead of selecting needed columns.
- A Scheduled Script processing an unbounded result set with no way to recover once it runs out.
- A reduce stage grouping thousands of records under one key: a heavily skewed key can exhaust even 5,000 units.
Checking your remaining budget
Scheduled Scripts, RESTlets, and Suitelets have no automatic yielding, so you monitor usage yourself:
require(['N/runtime'], function(runtime) {
const script = runtime.getCurrentScript();
log.debug('Remaining units', script.getRemainingUsage());
});
Check before an expensive operation, not after. Zero units at that point won’t help you save progress.
Rules of thumb
- Bulk operations → Map/Reduce almost every time.
- Single-record, real-time logic (validation, field sourcing) → User Event, kept lean.
- User-facing pages → Suitelet, retrieving only needed fields. For joins or aggregation, query.runSuiteQL() is the better tool.
- Unpredictable record counts → Monitor getRemainingUsage()and reschedule manually, or hand it to Map/Reduce.
Governance isn’t really about how many units a script gets. It’s about what happens once they’re gone. Map/Reduce is the only script type where running out is expected, and recovery is automatic. See it that way, and choosing between a User Event, Scheduled Script, or Map/Reduce gets a lot more straightforward.
How TAC Can Help
If governance limits are impacting your NetSuite processes, TAC Solutions Group can help identify the cause and implement a solution built to scale.
Our NetSuite development team can help optimize existing SuiteScripts, improve inefficient processes, and determine when a process should be moved to Map/Reduce or another script type.
Whether you’re troubleshooting SSS_USAGE_LIMIT_EXCEEDED errors or looking to improve overall script performance, our team can help.
