Acumatica Monitoring and Alerting

Monitoring an Acumatica instance is really three separate problems wearing one name: is the server up, is the application behaving, and are the business processes running to completion. Most teams only ever build the first one — a ping check on the URL — and then get blindsided when the app pool is technically alive but every AP bill posting is silently failing, or an integration scenario has been throwing errors for six hours with nobody watching. This is the setup I actually use to close that gap, split across infrastructure, application, and business-process layers.

The three layers you actually need

Infrastructure monitoring covers IIS app pool health, SQL Server wait stats and blocking, disk space on the database and file-attachment volumes, and application pool recycle events. On Acumatica Cloud (SaaS), this layer is mostly Acumatica's responsibility — you don't get RDP access to tune it, so your job shifts almost entirely to the layers above it. On self-hosted or IaaS deployments (Azure VMs, on-prem), it's still yours, and it's the layer most likely to be ignored until a disk fills up over a weekend.

Application monitoring is Acumatica watching itself: the trace log under System > Monitoring and Maintenance, license compliance warnings, import/export scenario run history, and the Automation Schedules screen, which shows you every scheduled process that failed silently overnight. Business-process monitoring is the layer almost nobody builds — alerts on conditions like "this AP bill has been on Hold for 3 days" or "this sales order hasn't shipped in 48 hours" — and it's the layer that actually matters to the business, not just to IT.

Business Events as the native alerting engine

Acumatica's Business Events feature (under System > Automation > Business Events) is the built-in way to turn a data condition into a notification, without writing a customization. You define a trigger — a DAC field change, a screen action, or a schedule — and attach subscribers that send an email, create a notification, or run a business process. For monitoring purposes, the schedule-based trigger is the useful one: run a generic inquiry every 15 minutes that flags bills stuck in Hold past a threshold, or integration records that failed and never retried, and email the result to whoever owns that process.

This is deliberately not APM. It won't tell you CPU usage or query latency. What it gives you is business-condition alerting that lives inside the same screens your accounting and ops teams already use, which means the people who actually need to act on the alert are the ones who see it — not a Slack channel full of infrastructure noise they'll learn to ignore.

public class APInvoiceEntry_Extension : PXGraphExtension<APInvoiceEntry>
{
    protected virtual void _(Events.RowPersisted<APInvoice> e)
    {
        if (e.Row == null || e.TranStatus == PXTranStatus.Aborted)
            return;

        if (e.Row.Hold == true)
        {
            PXTrace.WriteWarning(
                $"AP Bill {e.Row.RefNbr} entered Hold status " +
                $"(Vendor {e.Row.VendorID}, Amount {e.Row.CuryOrigDocAmt})");
        }

        // Long-running post-processing goes through PXLongOperation so it
        // shows up in the Processing screen instead of blocking the UI
        // and disappearing from view if it fails.
        PXLongOperation.StartOperation(Base, () =>
        {
            // integration push, PDF generation, etc.
        });
    }
}

Integration and import scenario failures

REST/SOAP integrations and Import Scenarios each keep their own error logs, but neither pages anyone by default. For anything pushing data to an external system — Azure Service Bus, a webhook, a middleware layer — build retry with backoff on the sending side, and treat repeated failures past N retries as dead-letter: log it somewhere durable and raise a Business Event or an external alert rather than letting it fail silently on attempt 47. The worst integration failures I've dealt with weren't caused by the integration breaking; they were caused by it breaking quietly three weeks before anyone noticed the numbers didn't reconcile.

Alert tiering so people don't tune out

The fastest way to make monitoring useless is to route every alert to the same channel at the same urgency. I split alerts into three tiers: critical (site down, database unreachable, integration completely stopped) goes to phone or SMS; warning (a bill stuck on Hold, a scheduled process that failed once) goes to Teams or Slack; informational (license usage climbing, disk space trending down) goes to email only, reviewed weekly. If everything pages someone's phone at 2 AM, the on-call person starts ignoring the phone, and that's worse than not having alerting at all.

Wrapping up

None of this needs to be elaborate to be useful — a handful of Business Events and a synthetic login check will catch most of what actually goes wrong in production. I've set this up for clients across Nairobi, Johannesburg, Kigali, Lusaka and Harare, usually after a failure that a dashboard would have caught weeks earlier. If you're trying to figure out what to monitor on your own instance, reach out or browse the rest of the Acumatica blog for related posts.