The quick answer
With deployment Log Level set to Error, Error and Emergency logging calls produce entries. The Execution Log's Type Error filter displays Error entries only. Existing Debug and Audit entries may remain visible after the threshold changes; this is not a retention guarantee. Use invocation markers to separate those entries, and check Map/Reduce execution status independently.
This walkthrough uses a prepared SuiteScript 2.1 Map/Reduce logger. It adapts a client-script demonstration to a server-only test, with four deliberate logging calls and no business-record changes. The recorded result is four deliberate retained messages from the Debug-threshold invocation, two from the Error-threshold invocation, and two completed jobs.
Before you start
Use a dedicated deployment of a prepared logging test. The example names it Log Threshold Review. Its map function calls log.debug(), log.audit(), log.error() and log.emergency() through N/log. The summary function adds no messages, and the test throws no deliberate exception.
Each message contains a generated invocation marker, input key, execution number and restart flag. Those values distinguish the controlled messages from older entries or repeated processing. The script imports no business-record API and creates no transaction.
The operator needs access to the script, deployment, status page and execution logs. This controlled example uses Administrator. Confirm that Deployed is checked and Status is Not Scheduled before manual submission. Keep the test's messages fictional and concise.
01. Inspect the prepared deployment
Open Log Threshold Review and confirm Log Level = Debug. Record the scheduling status and Deployed setting before changing anything.
The severity thresholds are ordered:
- Debug: Debug, Audit, Error and Emergency.
- Audit: Audit, Error and Emergency.
- Error: Error and Emergency.
- Emergency: Emergency only.
A logging threshold controls which logging calls produce entries in the Execution Log. The calls and surrounding JavaScript still execute when an entry is suppressed.
02. Run the Debug invocation
Choose Edit, open the save menu and select Save and Execute. Refresh the Map/Reduce status page until the submitted instance is Complete. Then return to this deployment's Execution Log and leave Type at - All -.
The first controlled invocation has four deliberate messages. All four share the same marker and show input key 0, execution number 1 and isRestarted: false.
Count these controlled messages by marker. Framework messages, other code or retries can change the total number of rows in a real deployment.
03. Save Error and run a second invocation
Edit only Log Level, choose Error and select Save. Confirm that Deployed and Not Scheduled remain unchanged.
Before executing again, inspect the existing log with Type = - All -. The original four rows remain visible, including Debug and Audit. Changing the threshold did not rewrite that history or recreate any previously suppressed entry.
Use Edit → Save and Execute to submit a second instance. Refresh its status, then compare both instances. Both finish Complete, even though the test deliberately logs Error and Emergency messages.
Return to Execution Log with Type = - All -. The newer invocation has a different marker and contributes only Error and Emergency. Its four logging calls still ran; the lower-severity messages were suppressed by the threshold.
04. Separate the Type filter from the threshold
Set the log view's Type to Error. The view displays one Error entry from each invocation. Emergency entries are hidden by this exact-type filter. This differs from an Error deployment threshold, which produces entries for both Error and Emergency calls.
Restore Type = - All -. In this controlled replay, the deployment history contains six deliberate messages: two from the newer Error-threshold invocation and four retained from the earlier Debug-threshold invocation.
The deployment threshold remains Error. Treat threshold, displayed message type, invocation identity and task status as separate facts. Complete does not establish that every intended business check passed.
Common questions
Why are old Debug rows visible when Log Level is Error?
They can belong to an earlier invocation. In this test, saving Error left the earlier four messages visible. Compare markers and timestamps before deciding which execution produced a row. This observation is not a long-term retention guarantee.
Does Error Log Level also accept Emergency?
Yes. At Error, Error and Emergency calls produce entries. The exact Type Error display filter shows Error entries only; restoring - All - makes the retained Emergency entries visible again.
Can a job be Complete when it logged an Error?
Yes. log.error() and log.emergency() assign message severity; they do not themselves throw exceptions. This logging-only test completed both instances. Check the intended result separately from job status.
What is different about a thrown exception?
A thrown exception interrupts an invocation; NetSuite's response depends on the stage and error-handling configuration. Inspect the relevant stage errors, including summary.mapSummary.errors during summarize for map-stage errors. This test throws no exception and does not demonstrate exception reporting or handling. Oracle documents the map-stage error iterator and responses to interruptions.
Does changing Log Level skip JavaScript?
No. It changes which logging calls produce entries. The four calls remain in this test's code. It also does not retroactively create entries suppressed during an earlier execution.
Should every run produce exactly six rows?
No. Six is the recorded controlled result across these two invocations. One logical input does not guarantee one map invocation when retries occur. Use markers, input keys, execution numbers and restart flags to investigate additional processing or log activity.
Do client scripts log in the same place?
Attachment matters. Record-level client-script N/log messages can appear in NetSuite. Client scripts attached directly to a form ignore N/log calls; use console.log and inspect the browser console for those messages. This walkthrough exercises server-side Map/Reduce logging.
How long will the entries remain available?
The Execution Log subtab and Server Script Log search are subject to a shared five-million-entry capacity per database. They are not guaranteed to retain every entry for 30 days; high volume can cause earlier purging. The separate Script Execution Logs page provides its documented 30-day log-details repository. None of these logging views should be treated as an audit archive.
Oracle also documents a company-wide allowance of 100,000 logging-method calls in 60 minutes. Excessive logging can automatically raise a script's log level. This example does not test that limit or adjustment. See Oracle's logging guidance and logging limits.