How to Kill a Script in NetSuite (SuiteScript Debugging 2026)

How to kill a script in NetSuite

To kill a running script in NetSuite, go to Customization > Scripting > Script Deployments, find the deployment, and change its status to Not Scheduled or Disabled. For scheduled scripts mid-execution, also cancel the queued task in Setup > Company > General Preferences > Scheduled Script Status (or via the SuiteCloud Processors page in newer accounts). NetSuite does not expose a direct "kill process" button — you stop a script by removing its trigger and waiting for the current execution to either finish or hit a governance limit.

Quick rule: there's no kill -9 in NetSuite. You either disable the deployment so it won't run again, or you let governance limits stop a stuck execution.

---

The 3 types of "stuck" scripts (and how to stop each)

Identifying which type of script is stuck determines the fix. The three common scenarios:

1. Scheduled script that's looping or running too long

Symptom: the same scheduled script keeps running, consuming governance, possibly preventing other scheduled scripts from executing.

How to stop it:

1. Go to Customization > Scripting > Script Deployments
2. Find the deployment (filter by Script Type: Scheduled)
3. Change Status from "Scheduled" to "Not Scheduled"
4. Save
5. Wait for the in-flight execution to hit its governance limit or complete (usually 60 minutes max for Scheduled scripts)
6. If urgent, also check Setup > Company > SuiteCloud Processors Status (or Scheduled Script Status in older UIs) and cancel the queued task

The deployment status change prevents new executions; the in-flight execution will exit on its own when governance runs out or when the loop completes.

2. Map/Reduce script stuck in a stage

Symptom: a Map/Reduce script shows status "Processing" indefinitely, or yields without progressing.

How to stop it:

1. Go to Customization > Scripting > Script Deployments, find the M/R deployment
2. Open the deployment record, click into the most recent script log
3. From the log, click Cancel (visible only on in-progress M/R jobs)
4. If Cancel is greyed out: change Deployment Status to "Not Scheduled" and wait for the current map/reduce stage to finish
5. After cancellation, clean up partial data — M/R scripts often leave inconsistent state if killed mid-process. Run a cleanup search or restore from a sandbox backup if needed

3. User Event or Client Script stuck on form save

Symptom: user clicks Save, browser hangs, save never completes (or completes after 5+ minutes).

How to stop it:

1. The user cannot kill it from the browser — closing the tab does NOT abort server-side User Event scripts
2. As admin: go to Customization > Scripting > Script Deployments, find the User Event script attached to that record type
3. Change Status to "Testing" (this disables it for non-admin users) or "Released" with the audience set to no roles
4. The current stuck save will eventually fail (record lock timeout, typically 5-10 minutes)
5. Investigate the script's logic — usually a runaway loop, an external API call without timeout, or a recursion bug

---

The "governance ran out" scenario (often a feature, not a bug)

NetSuite's governance system is a hard execution limit per script type:

Script Type	Governance Limit	Time Limit
User Event (beforeLoad/Submit/afterSubmit)	1,000 units	~5 min before record lock timeout
Client Script (pageInit/fieldChanged/saveRecord)	1,000 units	Browser-bound
Suitelet	1,000 units	~5 min HTTP timeout
Restlet	5,000 units	~5 min HTTP timeout
Scheduled Script	10,000 units	60 minutes wall clock
Map/Reduce	10,000 units per stage	Unlimited (multi-stage)
Mass Update	10,000 units	60 minutes
Workflow Action	1,000 units	Workflow timeout

When a script hits its governance limit, NetSuite automatically terminates it with a SSS_USAGE_LIMIT_EXCEEDED error. This is the platform killing the script for you — you don't need to do anything except investigate why governance was exceeded.

If your "stuck" script keeps running for an hour, it's a Scheduled or Map/Reduce script that's working as designed but consuming more than expected. The governance limit is the safety net.

---

How to find the runaway script

Before you can kill it, you need to identify which script is stuck:

1. Script Execution Logs: go to Customization > Scripting > Script Execution Logs, filter by date (last hour). Long-running scripts show up at the top with high execution times.
2. SuiteCloud Processors Status: shows currently-running scheduled scripts, Map/Reduce jobs, and queued tasks. Sort by Status = Processing.
3. Performance Health Dashboard (Setup > Performance > Performance Health Dashboard): shows account-wide bottlenecks. Long-running scripts appear in the "Top Time-Consuming Scripts" table.
4. Saved Search on Script Execution Log: build a saved search on the scriptlog record type, filter by Execution Time > 60 seconds, group by Script Name. Surfaces patterns of slow scripts you might not notice.

If multiple scripts are running and you can't tell which is hung, look at Script Execution Logs > Type: ERROR — most "stuck" scripts eventually log an error or timeout. The error log tells you the script and line.

---

Preventing scripts from running away

Killing a script is reactive. The real fix is preventing the loop, infinite recursion, or external API stall that caused it. Patterns we use:

• Always wrap external API calls with https.requestSuiteScript({ timeout: ... }). A SuiteScript that hits a slow third-party API without a timeout will sit and wait — sometimes for hours. Set a 10-30 second timeout, handle the timeout exception, and log.
• Yield governance proactively in Map/Reduce. Use nlapiYieldScript() (1.0) or rely on the M/R framework's automatic yielding (2.x) to checkpoint progress. If a script crashes, you don't restart from zero.
• Add a recursion guard on User Event scripts. If afterSubmit modifies the same record (causing another afterSubmit), use a custom field like custrecord_skip_ue to break the loop.
• Test in sandbox with production-volume data. A script that runs fine on 10 test records may explode on 100,000 production records. Always benchmark on realistic data volume before deploying.
• Use Saved Searches with paging instead of unbounded loops. search.runPaged() handles result set pagination; manual loops with getValue() on large result sets are a common stall pattern.

---

Common questions about stopping NetSuite scripts

Frequently Asked Questions

How do I kill a running script in NetSuite?expand_more

Can I force-stop a User Event script that's hanging?expand_more

How do I cancel a Map/Reduce script in NetSuite?expand_more

Why won't my SuiteScript stop running?expand_more

What is NetSuite governance and how does it stop scripts?expand_more

How do I find which NetSuite script is causing performance issues?expand_more

Can I rollback a SuiteScript that modified records incorrectly?expand_more

---

When to escalate to a NetSuite developer

If you've killed the deployment and the issue keeps recurring, you have a code-level bug — not an operational problem. Patterns we see:

• Infinite recursion in User Event scripts that trigger themselves
• External API stalls without timeouts (especially common in custom integrations)
• Memory leaks in long-running Map/Reduce jobs that accumulate state without yielding
• Race conditions between User Events on the same record (two scripts trying to modify the same fields)

These need a developer who understands SuiteScript's execution model. We build, audit, and fix SuiteScript code for companies that have outgrown their original implementation team. Talk to our team if you need help debugging a stuck script.

Related reading: NetSuite REST API guide · SuiteQL complete guide · NetSuite customization guide