Most NetSuite integrations are observed through a combination of NetSuite’s own execution logs, middleware platform dashboards, and whatever alerting the team set up during go-live. This is usually not enough. The integrations that have production incidents without warning are not the ones with no monitoring — they are the ones with monitoring that watches the wrong things.
The Right Unit of Measurement
Individual API calls are too granular to monitor meaningfully at volume. “The API call succeeded” is not a useful signal when the correct measure is “the order was created in NetSuite within 5 minutes of being placed on WooCommerce.” Monitor business outcomes, not infrastructure events. The infrastructure events are useful for debugging when something goes wrong; they are not useful for knowing that something is wrong.
The metrics that matter for an e-commerce integration:
- Order creation lag: time between WooCommerce order creation and NetSuite sales order creation. Alert when p95 exceeds your SLA threshold.
- Fulfillment sync lag: time between NetSuite fulfillment creation and WooCommerce order status update. Alert when p95 exceeds threshold.
- Error rate: percentage of records that fail to sync within the retry budget. Alert when this exceeds 1% over any 1-hour window.
- Queue depth: number of records waiting to be processed. Alert when depth exceeds expected maximum for the time of day.
What to Ignore
Transient 429 errors that retry successfully within the SLA are noise. Occasional NetSuite maintenance windows that cause a 5–10 minute gap in processing are noise. A single malformed record that fails validation and is routed to a dead-letter queue is not an alert — it is a known handling path. Alert fatigue from over-monitoring these events causes teams to ignore alerts, which causes them to miss the alerts that matter.
The Dead-Letter Queue Is Not Optional
Every integration needs a place for records that fail beyond their retry budget. This is not a failure of the integration — it is a designed handling path for data that cannot be automatically processed. What matters is that the dead-letter queue is visible, that it has an owner, and that there is a process for reviewing and reprocessing records from it.
Dead-letter queues that grow silently are the most common source of “we just discovered we’ve been missing orders for three weeks” incidents. A daily alert on dead-letter queue depth — even if the threshold is zero — ensures the queue is never forgotten.
NetSuite Execution Log Retention
NetSuite’s built-in execution logs for scheduled scripts and RESTlets are retained for a limited period. For integrations where auditability matters — and in any financial context, it does — export the relevant log data to an external system before it ages out. A structured log with timestamp, record type, record ID, operation, and result is enough. The goal is to be able to answer “was this order synced, and when” without relying on NetSuite’s retention schedule.