Atlas Diagnostic
SAP interface monitoring diagnostics
A first-pass structure for finding why interface monitoring misses failures, generates false alerts, or does not cover critical paths.
Core idea
Interface monitoring is only useful if it alerts the right person before the business reports the failure. Most monitoring gaps are not tool failures; they are scope gaps, thresholds set too high, jobs that stopped running, or new interfaces that were never onboarded. The diagnostic job is to compare what the tool checks against what actually failed.
Common symptoms
- Business users report missing data before the monitoring team is aware.
- Monitoring dashboard shows green status but IDocs are stuck in error.
- Alert fatigue from false positives causes real failures to be ignored.
- New interface went live but was not added to monitoring scope.
- Monitoring job fails or runs too slowly to catch issues in time.
Likely causes
- Monitoring scope gap: the monitoring job or tool only checks specific message types, partners, or status codes, missing others.
- Threshold too high: the alert threshold is set to a count or age that does not trigger for small but critical failures.
- Job failure or delay: the monitoring background job failed, was not scheduled, or runs infrequently.
- Wrong monitoring object: the tool monitors queue depth but not IDoc status, or monitors RFC but not application errors.
- New interface not onboarded: the interface was deployed without updating the monitoring configuration.
Where to check in SAP
- SM37 — background job log for monitoring jobs.
- WE02 / WE05 — IDoc status overview to compare with monitoring results.
- SMQ1 / SMQ2 — qRFC queue status if queue monitoring is used.
- SM58 — tRFC error log.
- SLG1 — application log for monitoring tool errors.
Key tables / transactions / objects
- EDIDC / EDIDS — IDoc control and status.
- TRFCQOUT / TRFCQIN — tRFC queue tables.
- TBTCO — background job status.
Diagnostic workflow
- Identify the interface path, message type, and partner that was not monitored.
- Check the monitoring job log (SM37) for failures, delays, or scope limitations.
- Compare the monitoring configuration with the actual IDoc or queue status in WE02 / SMQ1.
- Verify the alert thresholds: count, age, or status codes that trigger alerts.
- Check if the new interface was added to the monitoring scope during deployment.
- Review the escalation path: who receives alerts and whether they are actionable.
Typical fixes or next actions
- Expand the monitoring scope to cover all critical message types and partners.
- Lower the alert threshold or add secondary alerts for high-priority interfaces.
- Fix or reschedule the monitoring background job.
- Add new interfaces to monitoring as part of the deployment checklist.
- Tune the monitoring tool to reduce false positives while maintaining sensitivity for real failures.
What to capture first
Before routing the issue, capture: interface path, message type, partner, expected versus actual monitoring behavior, monitoring job name, and any recent change to the interface or monitoring setup. If the tool reports green while IDocs are stuck in error, the scope or threshold is usually wrong.
Boundaries and non-goals
This page is a diagnostic frame, not an interface monitoring configuration guide. It does not cover specific monitoring tools (SolMan, SAP Cloud ALM, third-party) or alert routing design. It does not replace SAP's operations documentation.
This is not official SAP documentation and not a replacement for system-specific analysis.