How to Monitor ERP Performance: What to Track and Alert On

Building ERP performance monitoring

1. 1Pick five to ten critical transactions: open a sales order, post a receipt, run an inventory inquiry, release a work order, print a pick list. Time them with a scripted synthetic check every few minutes.
2. 2Collect OS metrics on database and application servers: CPU, memory, disk latency, network, and for virtual machines CPU ready and ballooning.
3. 3Collect database health: top wait types, blocking chains, longest-running queries, log growth, tempdb or undo usage, index fragmentation and statistics age.
4. 4Track job duration for nightly and intraday batch work: MRP or planning runs, cost roll-ups, period-end jobs, interface imports and exports. Alert on both failure and duration far above baseline.
5. 5Monitor queues and integrations: pending messages, failed IDocs or API calls, middleware backlog, print queues.
6. 6Set baselines from two to four weeks of normal data and alert on deviation from baseline, plus hard limits for disk space and log size.
7. 7Route alerts to a named on-call with a short runbook per alert, and review noisy alerts monthly to prune them.
8. 8Keep at least 90 days of history so you can compare a complaint about last Tuesday against the data.

Database: waits, blocking and long queries

-- SQL Server: current blocking sessions and what they are running
SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time,
       s.login_name, s.program_name, t.text AS sql_text
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0
ORDER BY r.wait_time DESC;

Capacity trends and making it useful

Common pitfalls

• !Alerting on every CPU spike, which trains the on-call to ignore alerts that matter.
• !Monitoring servers but not the user experience, so slowness is discovered by phone call.
• !No history retention, making yesterday's slowdown impossible to investigate.
• !Ignoring custom reports and ad hoc queries run by power users directly against the production database.
• !Watching job failure but not job duration or silence from integrations.
• !Running statistics and index maintenance during peak hours, causing the slowness it was meant to prevent.