# How to Monitor ERP Performance: What to Track and Alert On > Source: https://netray.co/erp-help/itm-erp-performance-monitoring-what-to-track > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Monitor the ERP from the user's side first (response time of a few key transactions), then the layers beneath: database waits, blocking and long queries, application server health, batch and integration job duration, queues and storage. Baseline normal for each, alert on deviation, and keep history so you can answer slow-yesterday questions. ## Kind how-to ## System it-leadership ## Erp Any ERP with a relational database ## Module Operations / Performance Monitoring ## Query how to monitor ERP performance ## Alternate Queries - ERP slow what to monitor - ERP performance monitoring metrics and tools - how to find what is slowing down our ERP - ERP database blocking and long running queries monitoring ## Applies To Self-hosted ERPs on SQL Server, Oracle, DB2 or HANA: SAP, SyteLine, Infor LN, Dynamics, Epicor, JD Edwards. SaaS ERPs expose fewer layers but synthetic checks still apply. ## Steps ### Building ERP performance monitoring **Items:** - Pick 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. - Collect OS metrics on database and application servers: CPU, memory, disk latency, network, and for virtual machines CPU ready and ballooning. - Collect database health: top wait types, blocking chains, longest-running queries, log growth, tempdb or undo usage, index fragmentation and statistics age. - Track 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. - Monitor queues and integrations: pending messages, failed IDocs or API calls, middleware backlog, print queues. - Set baselines from two to four weeks of normal data and alert on deviation from baseline, plus hard limits for disk space and log size. - Route alerts to a named on-call with a short runbook per alert, and review noisy alerts monthly to prune them. - Keep at least 90 days of history so you can compare a complaint about last Tuesday against the data. ## Sections ### Start with what the user feels **Body:** Server graphs can look healthy while users wait. A synthetic transaction that logs in as a test user and times a representative screen tells you what users experience and when it started. Run it from a location that resembles the plant floor or branch office, not only from the data centre, so network problems show up. Pair synthetic checks with a simple way for users to report slowness: a help desk category with the screen name and time. Correlating three complaints about the same screen at 10:15 with a blocking chain in the database is how most root causes are found. Choose metrics the business understands. Seconds to open an order and minutes to finish the nightly planning run communicate better to management than CPU percentages, and they set clear service levels. ### Database: waits, blocking and long queries **Body:** The database is the most frequent bottleneck in transactional ERPs. Look at wait statistics to see where time goes: lock waits point to blocking and long transactions, I/O waits to storage, and CPU or parallelism waits to heavy queries or poor plans. A single poorly written custom report or a missing index can slow everyone for the duration of its run. Alert on blocking chains lasting more than a defined number of seconds and capture the head blocker's session, user and statement. Capture the top queries by total duration and by reads each day, so you can tie a slow period to a specific statement or job. Keep maintenance healthy: statistics updates and index maintenance on a schedule suited to your churn, and capacity trends for data and log files. Many sudden slowdowns follow an unnoticed plan change after statistics drift, or a full log volume. **Code:** -- 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; ### Batch jobs, integrations and queues **Body:** In manufacturing, many complaints are really about batch work overrunning into the morning shift. Record the start, end and row counts of planning, costing and period-end jobs, and alert when duration passes a multiple of its baseline. A job that takes twice as long as last month has usually met more data or a degraded plan, and it is cheaper to fix before it breaks the window. Integrations fail quietly. Track queue depth and age of oldest message for EDI, bank, MES, PLM and e-commerce links, and alert on failures and on silence, since a feed that stops sending produces no errors. A daily reconciliation count between ERP and the connected system catches the rest. Watch print and document services too. A stalled print queue or report server can look to users like the ERP being down, especially for pick lists and shipping documents. ### Capacity trends and making it useful **Body:** Performance management is not only firefighting. Trend data growth, concurrent users, transaction volume and storage consumption monthly, and forecast when you will hit limits. Present it with a simple traffic-light summary to management so capacity requests are backed by evidence. Document what normal looks like and write one-page runbooks for the top alerts: what it means, how to confirm, who to call, safe first actions. During an incident, a good runbook is worth more than another dashboard. Review after each significant slowdown: timeline, root cause, detection time and prevention. Over a year, the list of causes (a missing index, a runaway report, a full volume) tells you which monitors earn their keep. ## 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. ## Ai Angle An assistant such as ERPray, working read-only against the ERP's own tables, can answer operational questions like which scheduled jobs ran longest this week or which users posted the most transactions at the time of a slowdown, and it shows the query so you can check it. It does not replace database and infrastructure monitoring tools; it helps link a slowdown to business activity. ## Faq ### What are the most important ERP metrics to monitor? **Answer:** Response time of a handful of key transactions, database blocking and wait types, long-running queries, batch job duration, integration queue depth and age, and disk and log space. Add server CPU, memory and storage latency for context. User-facing timing should be the primary signal. ### Why is our ERP slow only at certain times? **Answer:** Usually a scheduled job, a report run by many users, or a month-end process competes for the same database resources, causing blocking or I/O saturation. Compare slow periods with job schedules and top queries by duration to find the overlap. ### Do we need a paid monitoring tool? **Answer:** Not always. Built-in database views, the OS performance counters and a free or inexpensive monitoring stack can cover most needs for a mid-size manufacturer. Paid tools add convenience, history and ERP-specific dashboards, which matter more as complexity and user count grow. ### How long should we keep performance history? **Answer:** Keep detailed data for at least 30 to 90 days and summarised daily figures for a year or more. Short retention makes it impossible to compare against last month-end, which is when many performance problems appear. ## Search terms monitor ERP performance, ERP slow performance troubleshooting, ERP database blocking, ERP monitoring metrics, ERP batch job duration, ERP synthetic transaction monitoring, ERP capacity planning, SQL Server wait stats ERP, ERP integration queue monitoring, ERP response time SLA --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json