Every daily critical scheduled process on my NetSuite test account started on every one of the thirty days reviewed. Not one instance failed or was cancelled. By the standard of any error dashboard, unattended processing on this account is perfect.
One of those processes, a job scheduler, completed 150 times in the period and has produced no business output since July 17. The job it dispatches failed 85 of 97 attempts in the first half of the year, and the script log that would have shown those errors retains four days. Another process ran six times a day, every day, against an input table with zero rows. Two monthly deployments show no run in their August windows. Six deployments can never fire again. And outside the critical set, a workflow is rewriting the same field on three subsidiary records 3,552 times a day.
The Missed-Run Audit of Scheduled and Map/Reduce Processing exists because a disabled deployment, an expired schedule, or a missed trigger produces no run to inspect, so a clean error log proves only that no recorded execution failed. It went into the Sonar AI Prompt Library in September. If you're new to this, Sonar AI is an AI agent that runs inside NetSuite. Every prompt in the library is a playbook that I engineered and tested against live NetSuite data, and you run it inside your own account, against your own records. Nothing leaves the account, and nothing is written to it.
Four Kinds of Failure
The report defines its terms before it counts anything. A recorded failure is an instance that ended failed or cancelled, and it's the only kind a conventional dashboard sees. A missed run is an expected window that passed with no instance at all. A no-output run completed and produced nothing. A degraded run completed with output but drifted from its own baseline in duration or volume. A dormant deployment can never fire again, whether because it's undeployed, not scheduled, past its schedule end date, or owned by an inactive employee. Only the first is visible without looking.
Every figure in the report carries an evidence grade: verified against the account with a workpaper ID, derived from verified data with the formula shown, or assumed and listed in the appendix with its impact if wrong.
The Population
680 scheduled and map/reduce deployments, 654 of them deployed, 28 live on a schedule, nine tested as critical, six dormant. The funnel is drawn to scale, and the 28 live ones are listed with their provenance, schedule, thirty-day instance count, and last completion.
The run expectations for the nine critical processes were set at a gate with the account owner, whose reply is quoted verbatim: use your suggestions based on best practices. So every expectation is marked assumed, and the windows are anchored on observed steady-state start times rather than the stored start time, because on this account the two differ by zero or four hours depending on the deployment. The report says that, rather than hiding it.
The Scorecard
Nine rows. Seven show thirty out of thirty days of adherence and zero recorded failures. Then the business-state column tells the other story. The payment batch process has no input to process. The lead-time calculation has a 29-day historical gap in its own last-run stamp. The job scheduler has zero writes since July. Two monthly deployments missed their August windows. The heatmap below it shows every day for every process, with the payment row in amber because its input table is empty rather than because runs were missing.
The observation on the job scheduler is written in condition, criteria, cause, effect, and recommendation form. The scheduler reports success for dispatching, not for the outcome of what it dispatched, and the outcome is written only to a custom record nobody reads. Six and a half months of failures produced no alert. The recommendation is one question, whether the product is in use, followed by either a vendor ticket or a status change to not scheduled.
The Runaway
The second high-rated observation wasn't in the critical set. 1,613,940 system notes since January 1, all on one field of three subsidiary records, in workflow context, at a constant 3,552 per day, cycling eighteen state nexus values every seven minutes. The candidate workflows are named. The effect is roughly 1.3 million audit rows a year from one process, subsidiary change history that's unreadable, and a nexus field that flaps with possible tax-determination side effects mid-cycle. The report grades the cause as assumed and says how to confirm it in an hour: read the one workflow's log, and if it isn't the actor, enable logging on the other for an hour and look again.
The Observability Budget
The section I'd show a NetSuite administrator is the table of what the account can and can't tell you about its own scheduled work. The instance table retains about thirty days and has no deployment column in SuiteQL. The script execution log retains four days. Deployment system notes go back to January. The recurring-event schedule is a record field, not a table, so 33 record loads were needed to read them. The conclusion is stated as an observation of its own: the account cannot answer whether a job ran in July from its own data, and the fix is a heartbeat record that the account owns and that persists.
What It Recommends
Today, decide whether the benchmark product is in use, and fix or unschedule. This week, attribute and suspend the nexus-rewrite workflow, and create two saved searches as interim absence monitors, both defined in the report and neither created. Confirm whether electronic bank payments is in use. Watch the two monthly deployments on their September dates and re-save their schedules if silent. Resolve the six dormant deployments by decision. Then approve the heartbeat control design in section eleven, which is the permanent version of the thing that didn't exist.
Everything was read-only. No record, field, script, deployment, workflow, or saved search was created or changed, and the report says so in the scope statement.
Wrapping Up
The Script Stacking Review in the same release looks at the scripts that run when a user saves a record. This one looks at the scripts that are supposed to run when nobody is there.
Missed-Run Audit is in the paid tier of the library. The full sample report from the test account is online, and I covered the whole September release in a separate post.
The first telemetry question for unattended work is whether the job showed up. On the test account, the answer was yes, thirty days out of thirty, and it was the wrong question.