Acumatica Business Events Monitoring

The Business Events screen shows an execution history — which events fired, when, against which record. What it doesn't show is whether whatever the subscriber was supposed to accomplish actually happened downstream. Monitoring a Business Events integration means watching two different things, not one.

Two layers that look like one

The first layer is "did the business event fire and did the subscriber run" — this is what Acumatica's own execution log covers, and it's reliable for that narrow question. The second layer is "did the effect the subscriber was trying to cause actually complete" — an email delivered, a webhook acknowledged, a queue message processed by the far end. Acumatica has no visibility into the second layer at all once a custom subscriber hands off to external infrastructure. Treating the execution log as proof of end-to-end success is the single most common monitoring gap in these integrations.

What to actually watch

Three numbers cover most of what matters: the count of rows in a Pending state older than some threshold (retry is stuck or too slow), the count in a Failed state (retry is exhausted, see the dead-letter article), and the age of the oldest unprocessed row. All three come from the same outbound queue table already described in the retry and DLQ articles — a small scheduled report or a Generic Inquiry against that table, itself wired to a Business Event on a schedule, is often enough to get the numbers into an alert without adding another system.

SELECT
    SUM(CASE WHEN Status = 'Pending' AND LastAttemptOn < DATEADD(minute, -30, GETUTCDATE()) THEN 1 ELSE 0 END) AS StuckPending,
    SUM(CASE WHEN Status = 'Failed' THEN 1 ELSE 0 END) AS Failed,
    MIN(CASE WHEN Status IN ('Pending','Failed') THEN CreatedOn END) AS OldestUnprocessed
FROM OutboundEventQueue;

Using a Business Event to monitor Business Events

A schedule-triggered Business Event against the query above, with an email or webhook subscriber that only fires when the stuck-pending or failed count crosses a threshold, is a reasonable way to get basic alerting without standing up a separate monitoring stack. It's a bit self-referential, but it works, and it means the alerting lives in the same place the rest of the integration does.

What good observability adds on top

Once volume or criticality justifies it, ship the queue processor's structured logs (attempt number, target, status code, latency) to whatever log aggregation the rest of the stack already uses, rather than relying only on the queue table's current state. The table tells you what's stuck right now; logs tell you the failure pattern over time — a target that's slowly getting slower, or one that fails reliably at a particular time of day, shows up in the logs long before it shows up as a threshold breach.

Wrapping up

Monitoring Business Events means monitoring the queue table downstream of the subscriber, not the Business Events execution log — the log confirms Acumatica did its part; the queue confirms whether the rest of the integration did.