I am trying to get a listing of when scripts run during the day along with the duration of the run, I created a saved search of the Server Script Log but that appears to only log entries that the script is programmed to log. There appears to be no default log entry of the start and/or end time of script execution if the script does not itself log those entries. I tried a saved search of Scheduled Script Instances and that gives me the start time of scheduled scripts but the end time is ALWAYS the same as the start time down to the minute. I know that we have scripts that take longer than a minute. ...and, unfortunately, that is only for scheduled scripts. Does anyone know a way to get more info on script execution?

probably easier just to install APM suiteapp from NetSuite

We have APM setup and it is great for performance evaluation but I am trying to do some proactive notification of issues. Like if a script suddenly starts taking longer that it should. I cannot tell if it has its own datasets that can be saved-searched.

ooooh... yeah that's trickier... sorry I don't have any bright ideas 😕

I'm not aware of any new datasets/properties that APM exposes to us, unless that is a recent addition. You'll likely need to build, track, and report those metrics yourself.

One approach ... instrumentation on steroids.... Event-Based Instrumentation Summary: Create a lightweight instrumentation framework where scripts publish execution events to topics at key points: • Script start (with context data) • Key milestones/checkpoints • Errors/exceptions • Script completion (with duration and outcome) Implementation Steps: 1. Define standard topic naming convention (e.g.,

scriptExecution/[scriptType]/[scriptId]

) 2. Create utility classes for consistent instrumentation 3. Subscribe monitoring/logging components to these topics 4. Implement dashboards/reports against the captured data Advantages: • Captures execution across all script types (scheduled, user event, etc.) • Provides precise timing information • Requires minimal code changes to existing scripts • Separates monitoring from business logic • Scales better than relying on built-in logging • Can capture contextual data (record types, IDs, etc.) Disadvantages: • Requires changes to all scripts you want to monitor • Slight performance overhead for each script execution • Need to manage storage/retention of monitoring data • Requires establishing governance around topic usage • Additional complexity compared to native solutions

// Example instrumentation utility
function ScriptMonitor(scriptId, scriptType) {
    this.scriptId = scriptId;
    this.scriptType = scriptType;
    this.startTime = new Date();
    this.checkpoints = {};
    
    // Publish start event
    N.topic.publish({
        topic: `scriptExecution/${scriptType}/${scriptId}/start`,
        message: {
            scriptId: this.scriptId,
            startTime: this.startTime,
            context: N.runtime.executionContext
        }
    });
    
    this.checkpoint = function(name) {
        const time = new Date();
        this.checkpoints[name] = time;
        
        N.topic.publish({
            topic: `scriptExecution/${scriptType}/${scriptId}/checkpoint`,
            message: {
                scriptId: this.scriptId,
                checkpointName: name,
                checkpointTime: time,
                elapsedSinceStart: time - this.startTime
            }
        });
    };
    
    this.end = function(status) {
        const endTime = new Date();
        const duration = endTime - this.startTime;
        
        N.topic.publish({
            topic: `scriptExecution/${scriptType}/${scriptId}/end`,
            message: {
                scriptId: this.scriptId,
                startTime: this.startTime,
                endTime: endTime,
                duration: duration,
                status: status,
                checkpoints: this.checkpoints
            }
        });
    };
}

I was afraid of that. To do what I want to do, it appears that I would need to edit every one of our scripts and add in a write to the execution log. Most have some log entry being created for some reason or another but not all and I would probably have to a simple execution start log entry.

Hm, if you only make a log entry, you won't be able to report on that very easily. If it's reporting/alerting you want, you might be better served by generating custom records with the metrics you're interested in. A background process can regularly comb the custom records and send out any relevant alerts. Users can build saved searches/queries against the custom records. You'd likely want to define a "TTL" for the custom records, though, and have a background cleanup process when they're no longer needed.

Not write to an execution log, but rather post to topics that resides outside of Netsuite and then you can report/read on those.

it appears that I would need to edit every one of our scripts

its worse than that... you can only do this for your custom scripts, any locked scripts from suiteapps/bundles you can't edit so you're SOL

*"*Fred Pope [1:52 PM] Not write to an execution log, but rather post to topics that resides outside of Netsuite and then you can report/read on those." ...I already do this. I send a whole bunch of data to a generic PowerAutomate "Webhook receiver" flow along with the name of a SQL stored procedure. The PA flow sends the SP name and JSON body to a generic stored procedure that launches the indicated stored procedure and passes the JSON. That stored procedure then parses the data into my Azure SQL Server for the required table.