Observability for NetSuite Integrations — What to Monitor, What to Alert On
- The three most important signals in NetSuite integration observability: sync lag (time from event in WooCommerce to record created in NetSuite), error rate per entity type, and governance consumption trend over time.
- Alert on error rate above 1% for any entity type over a 15-minute window — not on individual errors, which will generate noise.
- Governance consumption trending upward without a corresponding increase in order volume is a leading indicator of a script performance regression.
- The two things not worth monitoring at the integration level: individual API response times (too noisy, too variable) and WooCommerce queue size (a lagging indicator that tells you too late).
Most NetSuite integration monitoring setups are over-instrumented on the wrong things and blind to the signals that predict failure. Teams log every API call, alert on individual errors, and watch queue sizes in real time — then get surprised by a 6-hour sync backlog that started building 4 hours before anyone noticed. This guide covers the correct instrumentation and alert thresholds, based on production experience.
The Three Signals That Matter
Measure the time delta between the WooCommerce order’s date_created and the corresponding NetSuite Sales Order’s createdDate. Track the P50, P95, and P99. Alert when P95 exceeds your SLA (typically 10–15 minutes for a scheduled sync). A rising P95 is a leading indicator of queue buildup before the queue size makes it obvious.
Track error count and success count separately for: Orders, Products/Inventory, Customers, and Refunds. Calculate error rate as a percentage of total events per entity type. Alert when error rate exceeds 1% over any 15-minute window. This threshold prevents alert noise from transient single-record failures while catching systematic issues early.
Log the remaining governance units at the end of each NetSuite script execution. Track this as a time series. If governance consumption per order is trending upward (consuming more units per record over time) without a volume increase, a SuiteScript regression has introduced extra API calls or an inefficient loop. This is a code quality signal, not a capacity signal.
What Not to Monitor
Individual API response times (high variance, no clear threshold). WooCommerce action scheduler queue size (a lagging indicator — by the time it’s high, the failure has been happening for hours). Per-minute API call counts (too granular, obscures the pattern). Alerting on these will result in alert fatigue and missed real failures.
Recommended Observability Stack
| Layer | Tool | What it captures |
|---|---|---|
| Integration events | Structured JSON logs (CloudWatch, Datadog, Grafana Loki) | Sync events, errors, entity IDs, timing |
| Metrics + alerts | Datadog or Grafana | Error rate, sync lag P95, governance trend |
| Error notification | PagerDuty or OpsGenie (critical) + Slack (warning) | Route critical (error rate >1%) and warning (>0.5%) separately |
| NetSuite-side | Script Execution Log (native) + custom logging table | Governance consumed, SuiteScript errors |
References
- OpenTelemetry DocumentationCNCF — structured observability standard for integration event instrumentation.
- NetSuite Script Execution GovernanceOracle NetSuite Help — governance unit tracking and remaining usage APIs for consumption trend monitoring.
- Datadog Log ManagementDatadog — log aggregation and metric pipeline used in the recommended observability stack.
Leave a Reply