Finding silent errors and slow scripts in NetSuite

Performance · NetSuite

Most NetSuite problems do not announce themselves. A script catches an exception, writes one line to a log nobody reads, and the business runs on bad data for weeks. This guide shows where NetSuite records what your scripts did, how to read it before it disappears, and how an AI agent can read it with you.

What is a silent error in NetSuite, and why does it go unnoticed?

A silent error is a failure that leaves no visible trace for the people using NetSuite: the record saves, the job finishes, the integration reports success, but something did not happen. It goes unnoticed because the only evidence sits in a script execution log, and nobody is looking at it until a customer, an auditor or month-end close finds the gap.

The usual sources are the same in almost every account we review:

• Catch-and-log code. A try/catch that writes log.error and moves on. The record saves; the follow-up step never ran.
• Background scripts nobody watches. Scheduled and map/reduce scripts run at night, with no user to complain when one fails halfway.
• User event scripts with side effects. An after-submit script that updates a related record can fail while the record the user edited looks fine.
• Integrations that retry quietly. A connector that retries a rejected order and gives up produces a log entry, not an alert.

Where does NetSuite record what your scripts did?

Two places matter most: the script execution log and system notes.

The script execution log

Every log.debug, log.audit, log.error and log.emergency call writes an entry at that level. The Log Level field on each script deployment decides which entries are kept. Oracle describes Debug as the level "for scripts in testing mode" and recommends Audit, Error or Emergency for scripts going into production. You can browse entries across all scripts at Customization > Scripting > Script Execution Logs, filtered by log level, execution date range and script name.

The log does not keep everything. Oracle's governance rules for logging say:

• A company can make up to 100,000 N/log calls across all scripts within a 60-minute period. If a script logs excessively, NetSuite can raise its log level automatically and notify the script owner.
• User-generated logs are purged after 30 days and system error logs after 60 days.
• The Execution Log subtab and the server script log search share a limit of 5 million logs per database instance. When it is reached, the logs are purged for every customer on that instance.

System notes

System notes answer a different question: who changed this field, and when. Each note captures the date and time, who made the change, the interface it came from, the type of change, the field, and the old and new values. Oracle states that system notes cannot be edited by any user, script or app, and that they are logged on both standard and custom records. On a record, open System Information > System Notes.

Both are queryable. SuiteQL runs through REST web services as a POST to the suiteql resource, and system notes are available through the NetSuite2.com data source. One detail catches people out: without the Administrator role or the System Notes for Analytics and REST permission, you only see system notes for changes you made yourself.

How do you spot an inefficient script?

Every server script runs inside a governance budget measured in usage units. When a script is slow or fails at random, check how close it runs to the limit.

Then look for what eats that budget:

• Searches or record loads inside a loop. One search per line of a 200-line order is 200 searches. Run one search for all the lines instead.
• Loading the same record more than once in the same execution.
• Heavy work in user events and Suitelets. Oracle's governance best practices recommend handing high-volume I/O to a scheduled script, and using map/reduce for large data sets, because it yields and reschedules on its own.
• Gaps between log lines. Two audit entries with timestamps 40 seconds apart tell you exactly which block is slow. Call runtime.getCurrentScript().getRemainingUsage() at checkpoints and log it.
• Deployments left at Debug in production. They fill the shared log volume, push useful entries out sooner and hide the one error line you need.

How does an AI agent close the loop with an MCP server?

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems. An AI application, the host, connects to one or more MCP servers, and each server exposes tools the model can call.

Our team built vConnect MCP, an internal MCP server and command-line tool for NetSuite diagnostics. Its read-only server gives the agent:

• Script logs, filtered by script, level, time window and text, plus a follow mode that streams new log lines as they arrive.
• A script catalog: scripts, SSP applications, deployments and their log levels.
• System notes for the field change history of a record.
• Read-only SuiteQL, limited to SELECT statements.

The follow mode changed how we work. A developer exercises a Suitelet in the browser while the agent follows its logs live and proposes the next change:

1. Deploy the change to the sandbox.
2. Exercise it: open the Suitelet, save the record, run the job.
3. Read: the agent shows the new log lines and the governance used.
4. Fix, and repeat until the log is clean.

One finding from building it: SSP application logs land in the same execution log, under the web application's script.

A separate write server exists, and it is opt-in. It can only create or edit entries of custom record types whose owner is a VintenCloud employee, runs as a dry run by default, and keeps a local audit log of every change.

What safeguards should a diagnostics tool have?

Giving an agent access to an ERP is a security decision. These are the rules we built in:

• A read-only role. Authentication uses the OAuth 2.0 client credentials flow, which NetSuite describes as machine-to-machine with no user interaction. Each developer has their own certificate, mapped to a role that can read and nothing else.
• SELECT-only queries, enforced in code as well as by the role.
• Redaction and truncation of log details before they reach the model.
• One request queue per account. Web services and RESTlet requests share an account-level concurrency limit, so a diagnostics tool must never crowd out the integrations that run the business.
• No client data in tickets or repositories. Log content stays in the session that needed it.

Where should you start?

You can do three things this week without any new tooling:

1. List your script deployments and their log levels. Move every production deployment off Debug unless someone is actively debugging it.
2. Search your code for catch blocks that only log. Decide, for each one, whether it should rethrow, alert someone or write to a record a person reviews.
3. Check how many days of logs your account really keeps, by looking at the oldest entry on the Script Execution Logs page.

If you want a second pair of eyes on a slow or misbehaving account, talk to our NetSuite team.