# How NetSuite scheduled script queueing actually works

> Source: https://netray.co/erp-help/netsuite-scheduled-script-queueing-behavior
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

A Scheduled Script deployment queued behind other jobs is not failing; NetSuite runs a limited number of scheduled and Map/Reduce script queues concurrently per account, so deployments wait their turn based on account concurrency and deployment priority. The practical fixes are staggering trigger times, setting deployment priority correctly, and designing scripts that reschedule themselves cleanly with N/task instead of running one long unbroken execution.

## Kind

advanced

## System

netsuite

## Erp

Oracle NetSuite

## Module

SuiteScript 2.x / Scheduled Scripts

## Query

why is my netsuite scheduled script stuck in queued status

## Alternate Queries

- netsuite scheduled script queue concurrency limit
- netsuite scheduled script not starting on time
- netsuite scheduled script priority setting
- netsuite too many scheduled scripts queued

## Applies To

SuiteScript 2.x Scheduled Script type, all NetSuite editions; concurrency specifics vary with account provisioning and SuiteCloud Plus license

## Steps

### Diagnose and manage scheduled script queueing

**Items:**

Check Customization > Scripting > Script Deployments, filter to the deployment, and look at its status: Scheduled (waiting for its trigger time), Queued (waiting for a concurrency slot), Processing (running), or Complete/Failed.

If multiple deployments show Queued at the same time, the account has hit its concurrent scheduled/Map-Reduce execution limit; NetSuite processes queued jobs in priority order (High, Medium, Low) as slots free up, not strictly first-in-first-out across priorities.

Set deployment priority deliberately at the script deployment record: time-sensitive jobs (nightly close processes with a hard deadline) should be High, while best-effort cleanup jobs should be Low so they yield to more important work.

Stagger trigger times across deployments instead of firing several heavy jobs at the same minute (e.g. midnight); spreading them 5 to 15 minutes apart reduces self-inflicted queuing.

For scripts that legitimately need more than one execution's worth of governance or time, use N/task's ScheduledScriptTask to explicitly reschedule the next chunk from within the script rather than relying on NetSuite's automatic re-queue behavior alone.

Use runtime.getCurrentScript().getRemainingUsage() near the top of long loops and stop cleanly, saving a resumption point (for example, the last processed internal ID) to a custom record or script parameter, before governance runs out.

Avoid triggering a Scheduled Script from a User Event afterSubmit on every single record save if the same job could run in aggregate; frequent single-record triggers can flood the account's scheduled script queue during a busy period like month-end.

For jobs that must run and complete quickly (not tolerant of queuing delay), consider whether a Suitelet or client-triggered RESTlet with synchronous processing is more appropriate than a Scheduled Script, since queued execution timing is inherently best-effort.

## Sections

### Concurrency is an account-level resource, not per-script

**Body:**

NetSuite allocates a limited number of concurrent scheduled and Map/Reduce processing slots per account, and that limit is shared across every scheduled script, Map/Reduce script, and certain other background processes (like some workflow actions) running at once. It is not a per-script or per-deployment limit.

This means a spike in unrelated scheduled work (a large CSV import job, another team's nightly script, a burst of workflow-triggered scheduled scripts) can delay a script that would otherwise run instantly, and the delay has nothing to do with that script's own code or efficiency.

Higher concurrency is tied to account provisioning and license level (SuiteCloud Plus increases the ceiling); if queuing delays are a recurring operational problem rather than an occasional midnight pile-up, that is a provisioning conversation, not just a scheduling one.

### Priority, and what it does not guarantee

**Body:**

Deployment priority (High, Medium, Low) influences which queued job gets the next available slot first, but it does not guarantee a specific start time or bypass the concurrency ceiling entirely; a High priority job still queues if every slot is occupied by other High priority jobs already processing.

A common mistake is setting every deployment to High priority to 'fix' queuing, which just moves the contention point without changing the underlying available concurrency, and can starve genuinely low-priority housekeeping jobs indefinitely.

### Self-rescheduling patterns for long-running jobs

**Body:**

A Scheduled Script has both a governance unit budget and a wall-clock time limit per execution. For jobs whose total workload exceeds either, the standard pattern is to process a bounded batch, record a resumption marker, and submit the next execution via N/task's ScheduledScriptTask (or, in older code, runtime.getCurrentScript().deploymentId with a scheduling recall) rather than trying to force one execution to finish everything.

This produces a clean execution log per batch, which is far easier to audit and debug than one long run whose log mixes many unrelated iterations together, and it also plays more fairly with account concurrency since each batch is a normal, bounded job rather than one long-held slot.

**Code:**

define(['N/task', 'N/runtime'], function(task, runtime) {
  function execute(context) {
    var remaining = runtime.getCurrentScript().getRemainingUsage();
    // ... process a bounded batch ...
    if (moreWorkRemains && remaining < 200) {
      var scheduledTask = task.create({ taskType: task.TaskType.SCHEDULED_SCRIPT, scriptId: runtime.getCurrentScript().id, deploymentId: runtime.getCurrentScript().deploymentId });
      scheduledTask.submit();
    }
  }
  return { execute: execute };
});

## Pitfalls

- Assuming a Queued deployment has crashed and manually re-triggering it, creating a duplicate execution once the original clears the queue.
- Setting every deployment to High priority, which removes the intended prioritization signal without adding concurrency.
- Scheduling several heavy jobs at exactly the same trigger time and then blaming NetSuite for the resulting queue.
- Writing a Scheduled Script that assumes it will always complete in one execution, with no resumption logic, so it silently stops partway through on a busy day.
- Triggering a Scheduled Script from a high-volume User Event afterSubmit without batching, flooding the queue during peak transaction volume.

## Ai Angle

ERPray can be pointed at an account's script deployment records and recent execution logs and explain, in plain language, whether a specific run was genuinely delayed by account concurrency, blocked by a script error, or waiting on its own scheduled trigger time, which is often the first question a support ticket needs answered before anyone touches code. For teams designing a new long-running job, SyteRay-style scaffolding of the batch-and-reschedule pattern with N/task saves reimplementing it from scratch each time.

## Faq

### Can I increase how many scheduled scripts run concurrently in my account?

**Answer:** Concurrency is tied to account provisioning and license level, particularly SuiteCloud Plus, rather than being a setting on an individual deployment. If queuing is a persistent operational bottleneck, that is a provisioning question, not something a deployment configuration alone can change.

### Does a queued scheduled script count against its own governance budget while waiting?

**Answer:** No, governance and wall-clock limits only apply once the script actually starts processing. Time spent in Queued or Pending status waiting for a concurrency slot does not consume any of the script's own execution budget.

### Why did my scheduled script run at a different time than its trigger time?

**Answer:** The trigger time is when NetSuite attempts to start the job, but if every concurrency slot is occupied at that moment, the job queues and starts as soon as a slot frees up, which can be minutes later during busy periods.

### Is it better to use one big scheduled script or several smaller ones?

**Answer:** It depends on the workload: several smaller, well-staggered jobs are easier to reason about and less likely to collectively exhaust concurrency, but for one large dataset, a single script that reschedules itself in bounded batches via N/task is usually more reliable than trying to split the same logical job into many independently triggered deployments.

## Search terms

netsuite scheduled script queued status, netsuite scheduled script concurrency limit, netsuite script deployment priority, netsuite scheduled script not starting, N/task ScheduledScriptTask, netsuite scheduled script self reschedule, netsuite suitecloud plus concurrency, netsuite scheduled script pending vs processing

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json