An RFC destination can return a successful connection test in SM59 at 09:00 while the system on the other end stopped processing incoming calls at 07:30. The test checks whether a network path exists. It does not check whether anything on the receiving end is running, reading, or posting the data it receives. You will get a green light on the connection and no indication that every message sent since 07:30 has been silently dropped.
That is the defining characteristic of interface failures in SAP environments: the most damaging ones do not announce themselves as errors. They look like operational silence. The interface is technically active. Messages are technically being sent. No error status is raised on the sending side. The failure only surfaces when a business user asks why the inventory update from the warehouse management system has not posted, or why the customer invoices from the billing run are not appearing in the EDI partner’s system.
This article covers the specific failure modes that make SAP interface monitoring different from other monitoring domains, the metrics and signals that catch silent failures before they reach the business, and the monitoring coverage that is worth building across the IDoc, RFC, API, and business process layers.
Why interface failures are different from other SAP monitoring problems ?
The error that does not look like an error
Most SAP monitoring is built around error states: a job with status ABORTED, a work process in error, a system that stops responding. These are visible failures. Something is clearly wrong, an alert fires, and the operations team investigates.
Interface failures frequently do not produce a visible error state on the sending side. An IDoc dispatched to an EDI subsystem stays in status 02 indefinitely if the EDI system stopped picking up messages. No new error is raised. The IDoc count at status 02 just keeps growing. A qRFC queue fills with outbound messages because the receiving system is under load and processing slowly. No error fires until the queue hits a configured limit, and many systems do not have that limit configured. An HTTP endpoint responds with a 200 status code but the response body contains an error message that the sending integration layer is not parsing.
The monitoring coverage that catches these situations is different from threshold-based alerting on error counts. It requires watching states that are technically not errors but are operationally abnormal: messages that have been in dispatch status longer than expected, queues that are growing when they should be draining, volume patterns that deviate from what is normal for the time of day.
Why volume matters as much as error rate ?
A well-functioning order-to-cash interface in a manufacturing company processes several hundred ORDERS05 IDocs per hour during business hours. It processes zero IDocs overnight. Both of those states are normal.
A state that is not normal: zero IDocs at 10:00 on a Tuesday morning when orders should be flowing. That is not an error state in any SAP transaction. BD87 shows no errors. WE05 shows nothing in the queue. The interface looks healthy because nothing is failing. What is actually happening is that no messages are being sent, which means something upstream has stopped generating them.
Volume-based monitoring, watching whether message throughput matches the expected pattern for the time of day and the business calendar, catches this category of failure. An interface that processes 400 IDocs per hour on Tuesday mornings and is currently at zero after 30 minutes of the business day is not failing. It is absent. The distinction matters because the remediation for a processing failure (something is erroring) is different from the remediation for a volume drop (something upstream has stopped sending).
Volume anomaly detection requires historical baselines per interface and per time window. It is more complex to configure than error count alerting, which is why most monitoring setups skip it. It is also what catches the silent failures that cause the most business impact.
IDoc monitoring: beyond status codes
The status codes that deserve immediate attention
IDocs in SAP have over 70 status codes covering every step of outbound and inbound processing. Most of them are informational. A subset of them represents states that require immediate attention in a production environment. The table below covers the ones with the most operational relevance.
Eight status codes account for the vast majority of IDoc incidents worth monitoring. Among error states, status 51 (error posting) is the most frequent in production: the IDoc reached the inbound processing step but failed to create the SAP document. Root causes range from missing master data to authorization failures to incorrect message type configuration. Status 51 almost always needs a business user or functional consultant, not just Basis. Routing it to a generic Basis inbox adds hours to resolution time.
Status 25 (processing failed) and status 26 (syntax check error) indicate problems on the sending or mapping side. Status 25 often points to the EDI subsystem or the outbound ABAP program. Status 26 means the IDoc was generated with a structural error, which is a code or configuration issue on the sender.
Two intermediate states deserve specific attention even though they are not error codes. Status 02 and 12 (dispatched to EDI subsystem, ALE variant) mean the IDoc was sent to the next processing layer. Technically not an error. But an IDoc sitting in status 02 for four hours during business hours is operationally abnormal. Age-based alerting on these statuses, not just error-based alerting, is one of the more valuable configurations to add and one of the least commonly implemented.
Status 64 (ready to be passed to application) is the inbound queuing state. A few items at any moment is normal. A growing backlog is not. Monitor the count of IDocs in status 64 over a 15-minute window. If it is rising rather than clearing, inbound processing capacity is failing to keep up, and the upstream cause is worth finding before the backlog grows large enough to affect business deadlines.
IDocs stuck in processing: the queue that grows without any alarm
Status 64 represents inbound IDocs that have been received and are queued for application posting, waiting for an available process. Under normal load, this queue clears quickly. A few items in status 64 at any given moment is expected. A growing backlog in status 64 is not.
The backlog grows when inbound processing capacity cannot keep up with inbound volume. This happens when the background work processes allocated to IDoc inbound processing are occupied by other jobs, when the inbound processing program itself is slow due to a performance regression, or when a preceding IDoc in the same processing sequence is stuck and blocking subsequent ones.
Monitoring the count of IDocs in status 64 over a 15-minute rolling window, and alerting when that count has grown rather than shrunk, catches capacity problems before they cause visible delays in the business processes that depend on the inbound data.
The IDoc that completed but posted the wrong thing
Status 53 is the IDoc success code: application document posted. For most monitoring configurations, an IDoc at status 53 is a closed case. The interface worked. Nothing to watch.
This assumption is correct for most IDocs. It is wrong for message types where the business validation logic is weak or where the mapping from the external format to the SAP document is complex. An ORDERS05 IDoc can complete with status 53 and create a sales order with an incorrect ship-to party if the partner determination configuration has a gap. A DESADV (delivery note) IDoc can post successfully and create a goods receipt against the wrong purchase order line if the MBLNR reference handling has an edge case.
This category of failure is not catchable at the IDoc layer. It requires business process monitoring: checking whether the documents created by the interface make sense in context. A goods receipt posted against a purchase order that was already fully received, or a sales order created with a zero-value line item, are signals visible in the business data that indicate an interface posted something it should not have.
Not every interface warrants this level of monitoring. The ones that do are the high-volume, business-critical flows where a systematic data error in the posting logic would take days to detect manually and affect hundreds of documents before anyone noticed.
RFC and qRFC monitoring: connections that look alive but are not
SM59 connection tests are not health checks
The standard method for verifying an RFC destination is the connection test in SM59: select the destination, press Test, see a green result. This test confirms that a network path exists between the SAP system and the target host and that the target system responds to an initial handshake. It does not confirm that the application behind that connection is running, that it is processing incoming RFC calls, or that the user account configured in the destination has the authorizations needed to execute the function modules being called.
An RFC destination that passes the SM59 test but whose receiving application crashed 20 minutes ago will still pass the test the next time it is run. The test is checking the network, not the application. This is an important distinction when an interface is failing silently: a successful SM59 test is not evidence that the interface is working, and using it as such leads to wasted investigation time.
What does constitute evidence: a recent successful tRFC call in SM58 that was dispatched and confirmed received, or an active qRFC message that was processed and cleared from the queue. Monitoring should look at transaction-level evidence of successful processing, not connection-level evidence of network reachability.
qRFC queue depth as an early warning signal
Queued RFC delivers messages in FIFO sequence to a registered queue on the receiving system. Each queue has a name, an associated application server, and a processing program. When everything is working, messages enter the queue and are processed quickly enough that the depth stays low. When the receiving side is slow, busy, or unavailable, the queue depth grows.
Queue depth growth precedes hard errors. The messages are not failing yet. They are waiting. But a queue that has grown from its normal depth of 5 to a depth of 200 over the past hour is a system under stress. It will eventually start failing if the condition causing the buildup is not resolved. Alerting on queue depth growth, rather than waiting for the queue to produce errors, provides the operations team with lead time to investigate and intervene.
The relevant monitoring thresholds are specific to each queue and its normal processing pattern. A queue that normally runs at a depth of 2 and is now at 50 is more alarming than a queue that runs at a normal depth of 80 during batch windows and is at 90. Generic thresholds applied uniformly across all qRFC queues produce noise for some and miss real problems in others.
Blocked queues: what SYSFAIL and CPICERR actually mean
A qRFC queue in SYSFAIL status has encountered a system-level error: typically a connection problem, a timeout, or a failure in the queue registration on the receiving system. The queue stops processing. All messages behind the failing one remain queued. They are not being delivered, and no individual message error is raised for each of them.
CPICERR indicates a CPI-C communication error, which typically means the receiving system refused the connection or the call. Both states require manual intervention to resolve: either fixing the underlying connectivity issue and releasing the queue, or relocating the queue to a different application server if the registered server is unavailable.
The monitoring requirement for blocked queues is simple and absolute: any queue in SYSFAIL or CPICERR status in production requires immediate attention. There is no acceptable threshold. One blocked queue in production is one too many, because a blocked queue is not a degraded state; it is a stopped state for every message in that queue.
| Watch out: Queue blocking does not raise an alert in SAP’s standard monitoring unless configured explicitly. The default behavior is that a blocked queue sits silently in SMQ1 until someone opens the transaction manually. In environments without active qRFC queue monitoring, blocked queues are discovered by business users reporting missing data, not by the operations team. |
API and middleware integrations: where monitoring gets harder
HTTP 200 is not a success confirmation
REST and SOAP integrations between SAP and external systems use HTTP as the transport layer. HTTP response codes are the primary signal for connection-level success or failure: 200 means the request was received and a response was returned, 4xx means the request was rejected, 5xx means the server encountered an error.
The problem is that 200 means the response was returned, not that the response contains a success. A receiving system that accepted the payload but encountered a business logic error when processing it often returns HTTP 200 with an error body: a JSON object with an error code, an XML response with a fault element, or a plain text response containing an exception message. The SAP-side integration layer sent the message, received a 200, logged it as successful, and moved on. The receiving system did not process it.
Monitoring HTTP integrations at the response code level only catches hard technical failures. Monitoring at the response body level, parsing the content to verify that the response indicates actual success rather than a wrapped error, is what catches the cases where the transport worked but the business operation did not. This requires the integration layer to implement response body validation, not just status code checking.
Monitoring SAP Integration Suite and BTP-based flows
SAP Integration Suite (formerly SAP Cloud Platform Integration) routes and transforms messages between SAP and external systems. Its failure modes are different from direct RFC or IDoc interfaces because it introduces an additional layer with its own error handling, retry logic, and message store.
An Integration Suite flow can fail in several ways that are not visible on the SAP side: the flow adapter cannot reach the target endpoint, the message transformation produces a mapping error, the retry policy exhausts all attempts and the message is moved to the error queue. All of these states are visible in the Integration Suite Operations view in the BTP cockpit, not in any SAP transaction.
For SAP teams accustomed to monitoring from ABAP-based transactions, this creates a visibility gap. The SAP system successfully sent the message to Integration Suite. Integration Suite is where the problem occurred. Without monitoring coverage that spans both the ABAP SAP layer and the BTP layer, the investigation starts with half the picture.
Practically, this means that interface monitoring for BTP-integrated landscapes needs to include the BTP Operations monitoring as an explicit scope item, not as something the cloud team handles separately. Message error counts, failed flow instance counts, and adapter error rates from Integration Suite are as relevant to the overall interface health picture as SM58 and BD87 data.
SSL certificate expiry: the most preventable interface outage
SSL certificates on RFC destinations, HTTPS endpoints, and middleware connectors expire. When they expire, the connection fails with a certificate validation error and the interface stops immediately. No gradual degradation, no warning period, no automatic renewal in most SAP configurations.
This is one of the most preventable categories of interface failure. A certificate expiry is scheduled. The expiry date is known in advance. An alert configured to fire 30 days before expiry gives the team time to renew and deploy the certificate with no urgency. An alert configured at 7 days gives adequate time in most cases. No alert means discovery at expiry time, during working hours if the team is fortunate, during a weekend if they are not.
Monitoring SSL certificate expiry is not complex. It requires a list of endpoints with certificates, a scheduled check of each certificate’s expiry date, and an alert threshold. The monitoring setup takes a few hours. The interface outage it prevents takes much longer to resolve, especially if the certificate renewal process involves an external CA and requires lead time.
End-to-end flow monitoring: connecting technical health to business outcomes
When the interface works but the business process does not ?
Technical interface monitoring, covering IDoc statuses, RFC queues, and HTTP codes, tells you whether the data transport layer is functioning. It does not tell you whether the business process that depends on that data is functioning. An interface can process every message without errors while the business process it supports has stopped working because the data being processed is wrong.
The example that appears most often in practice: an inbound ORDERS05 interface processing without errors, creating sales orders in SAP, while a pricing condition that was updated in the sending system is not reflected in the SAP pricing determination. Every order posts. Every IDoc reaches status 53. The business discovers the pricing error when the first invoices go out with incorrect amounts. Technical monitoring showed green throughout.
Business process monitoring closes this gap by checking outcomes, not just transport status. Did the sales orders created by the interface have expected margin ranges? Did the inventory movements post to the expected storage locations? Did the inbound invoices match automatically or go to manual review at a higher rate than usual? These are business-layer signals that technical interface monitoring does not produce.
Implementing business flow monitoring requires collaboration between the IT operations team and the process owners to define what a healthy outcome looks like for each interface. It is more effort to build than status code monitoring. It catches the failure mode that causes the most expensive incidents: correct processing of incorrect data.
Volume anomaly detection as a complement to error alerting
Every interface in production has a normal volume pattern. Some are constant, processing a steady flow of messages throughout the business day. Some are batch-oriented, producing a spike at a specific time and then going quiet. Some are calendar-dependent, with higher volumes on specific days or at specific times of the month.
Building a volume baseline per interface, by hour of day and by day of week, enables a class of alerts that error monitoring cannot provide: the alert that fires when a normally active interface has gone quiet. Zero messages processed in the last 30 minutes by an interface that normally processes 200 per hour is not an error condition. It is an absence. But it is an absence that represents a business risk identical to an interface processing errors: the downstream process is not receiving data.
Volume anomaly detection requires at least four weeks of baseline data before alerting thresholds are meaningful, because weekly and monthly patterns need to be captured to distinguish genuine anomalies from expected low-volume periods. The configuration investment is worthwhile for interfaces that are critical enough that a volume drop of two hours would have visible business impact.
Interface monitoring coverage reference
The table below organizes the monitoring metrics discussed in this article by layer, with the relevant SAP source or view, a practical alert threshold, and the recommended monitoring action for each.
| Metric | Source / view | Alert threshold | What to do |
| IDOC LAYER | |||
| Error IDoc count | BD87 / WE05 | Any errors in production | Alert immediately with IDoc number, message type, and partner. |
| IDocs stuck in status 02/12/64 | WE05 / WE09 | > 10 items older than 30 min | Indicates EDI subsystem not processing or inbound queue stalled. |
| IDoc volume by message type | WE05 aggregated | Drop > 30% vs hourly average | Volume anomaly catches silent failures before errors appear. |
| Failed IDoc retry count | BD87 | > 3 retries on same IDoc | Repeated failures indicate a systemic issue, not a transient one. |
| RFC / QRFC LAYER | |||
| SM58 stuck entries | SM58 | Any entry older than 5 min in production | tRFC entries that do not process indicate receiver-side or network issues. |
| qRFC queue depth (outbound) | SMQ1 | > 50 entries sustained | Queue buildup indicates the receiver is slow or unresponsive. |
| qRFC queue depth (inbound) | SMQ2 | > 50 entries sustained | Inbound backlog impacts posting latency for all dependent processes. |
| Blocked queue status (SYSFAIL/CPICERR) | SMQ1/SMQ2 | Any blocked queue | A blocked queue stops all subsequent messages in that queue, regardless of content. |
| HTTP / API LAYER | |||
| HTTP error rate per endpoint | ICM logs / middleware | > 1% over 15-min window | HTTP 500 and 503 rates indicate receiver-side instability. |
| API response time trend | Middleware / BTP | > 2x baseline sustained | Latency growth often precedes hard errors. Catch before SLAs are breached. |
| SSL certificate expiry | Certificate store | < 30 days to expiry | Alert at 30 days. Expired certificates cause immediate connection failure with no graceful degradation. |
| Integration Suite flow error rate | SAP BTP Operations | > 0.5% per hour | BTP flows fail silently without ITSM integration. Monitor at the platform level, not just at the SAP side. |
| BUSINESS FLOW LAYER | |||
| Order-to-delivery gap | Custom ABAP / monitoring | Open orders > X hours without delivery creation | Detects interface failures that processed without errors but did not trigger downstream steps. |
| Inbound invoice match rate | Custom ABAP / monitoring | < 95% automatic match | Declining match rate indicates data quality issues in the inbound interface payload. |
| Message volume vs business calendar | Interface monitor | Volume drop on expected high-traffic day | Zero messages on a Monday morning when orders should be flowing is a business-visible signal. |
The interface layer is where most SAP blind spots live
Interface monitoring gets less systematic attention than application server monitoring or database monitoring, partly because it spans multiple systems and ownership boundaries, and partly because the failure modes are less obvious. A database that stops responding is immediately visible. An interface that is processing messages without delivering business outcomes requires a different kind of attention to catch.
The coverage that makes the difference is the combination of three layers. Technical transport monitoring, covering IDoc statuses, RFC queues, and API error rates, is the baseline. Volume anomaly detection is the layer that catches the failures that produce no error. Business flow monitoring is the layer that catches the failures that produce correct transport with incorrect outcomes.
Most SAP environments have some version of the first layer. Very few have the second, and fewer still have the third. The gap between the first layer alone and all three is the gap between monitoring that catches what SAP explicitly flags as wrong and monitoring that catches what the business will eventually flag as wrong. The latter is what prevents the Friday afternoon call about why last week’s deliveries did not ship.
Redpeaks monitors SAP interfaces across IDoc, RFC, qRFC, HTTP, and BTP layers from a single agentless connection, with volume baseline alerting and ITSM integration that routes each alert type to the right team.
