NetSuiteFree calculatorPDF, Excel, Word exportNetSuite

SuiteScript Scheduled Script Run Count Calculator

A scheduled script that works on 500 records in testing can quietly stop at record 800 in production because it ran out of governance units. This calculator tells you how many runs a given volume needs so you can design the yield or reschedule logic up front.

Your numbers

records
units

Sum of API unit costs for everything you do per record: load, field set, save, lookup.

units

Scheduled scripts have a per-run governance allowance. Confirm it in the current NetSuite help.

units

Units you hold back to save state and reschedule safely.

seconds
minutes

Time a rescheduled deployment waits before starting.

Your results

Records per run
816
Runs required
31
Total governance units
300,000
Usable units per run
9,800
Processing time
250 min
Elapsed time including queue gaps
310 min

Unit costs vary by API call and record type. Measure with runtime.getCurrentScript().getRemainingUsage() in a sandbox before committing to these numbers.

Save results:

Runs required vs records processed

Sweeps Records to process from 1000 to 100000, holding your other inputs fixed.

Scheduled script review

Optional: send us a script outline and we will flag governance and restart risks.

Optional. The tool and every export work without this. No spam.

How to use it

Count the API calls your script makes for one record: a record.load, several setValue calls, a save, perhaps a search.lookupFields. Add their unit costs from the NetSuite help to get units per record. Enter your expected record count and the per-run limit. Keep a reserve so the script can write its state and reschedule before it hits zero. The calculator returns how many records fit in a run, how many runs you need and the elapsed time including the queue gap between reschedules.

The math

Usable units equal the limit minus the reserve. Records per run equal usable units divided by units per record, rounded down. Runs equal total records divided by records per run, rounded up. With 12 units per record, 10,000 units and a 200 unit reserve, each run handles 816 records, so 25,000 records need 31 runs. That is a strong signal to consider a map/reduce script, which spreads work across many small governed jobs instead of one long chain.

  • Usable = limit - reserve
  • Records per run = floor(usable / units per record)
  • Runs = ceil(records / records per run)
  • Elapsed = processing time + queue gaps between runs

Reading the output

If runs is 1 you have no rescheduling logic to build, but keep a check on remaining usage anyway because data volumes grow. If runs is between 2 and about 10, a scheduled script with a saved cursor works well. Beyond that, elapsed time is dominated by queue gaps and a single failed run can strand a long chain, so map/reduce or splitting the work by subsidiary or date range is usually the better design.

Common mistakes

The most frequent error is counting only the obvious calls. Transaction loads and saves cost far more units than a simple search, and sublist operations add up. The second is rescheduling without persisting the last processed internal ID, which reprocesses records. The third is ignoring script timeouts: a script can fail on time before it fails on units.

  • Log getRemainingUsage at start, mid-run and end in a sandbox
  • Persist a cursor such as the last internal ID
  • Make the processing idempotent so a restart is safe
  • Use submitFields instead of load and save where possible

Frequently Asked Questions

What is the governance limit for a scheduled script?

Scheduled scripts have a fixed governance allowance per execution, and the value has changed between releases and script versions. Use the current NetSuite help for your SuiteScript version and enter it in the calculator.

How do I find units per record?

Add up the documented unit costs for each API call in your per-record code, or run a small sample in a sandbox and log the difference in remaining usage before and after one record.

When should I use map/reduce instead?

When the volume needs more than a handful of runs, when records are independent, or when you want parallel processing and built-in restart handling. Map/reduce governs each stage invocation separately.

Does the reserve matter?

Yes. If you spend every unit on records, the script has nothing left to save its cursor or reschedule, and the next run cannot continue where this one stopped.

If you have long running scheduled scripts that are fragile, Netray can help review them and plan a migration to map/reduce.

Talk to an ExpertExplore More Free Tools

Related Tools

NetSuite

NetSuite Map/Reduce Parallelism Throughput Calculator

Estimate map stage runtime, speed-up and efficiency from the processor count you configure and the share you actually receive.

NetSuite

NetSuite SuiteQL Pagination Time Calculator

Calculate pages, round trips and total extraction time for a large SuiteQL result set, and see how page size and parallel threads change it.

NetSuite

NetSuite Customization Maintenance Cost Calculator

Put a yearly number on SuiteScript and workflow upkeep: break-fix hours, release regression testing and the cost per script.

NetSuite

NetSuite API Concurrency Limit Calculator

Turn request rate and response time into concurrent requests, compare against your account limit, and find the maximum safe call rate.

More NetSuite tools

See all
Back to All Tools