SAP CPI Logging Limits: Debug, Trace, Payload Visibility, and Retention
SAP Cloud Integration, commonly referred to as SAP CPI, has separate limits for log-level activation, message processing log retention, trace data retention, and Message Processing Log (MPL) attachment storage.
These limits are easy to conflate during incident investigation. Debug and Trace have different activation periods. Trace captures message content but expires quickly. Message Processing Logs have a longer retention period, while MPL attachments are subject to a separate write limit.
Understanding the distinction matters when an integration fails and the information needed for root-cause analysis is no longer available.
This article explains the main SAP CPI logging limits, what Debug and Trace actually capture, how long monitoring data remains available, and what options teams can consider when standard logging is not sufficient.
How Long Does SAP CPI Keep Debug and Trace Logs?
Debug and Trace are not long-term logging mechanisms. They are diagnostic log levels intended to provide additional information while investigating integration-flow execution. The most important distinction is that Debug does not capture message content in the same way Trace does.
SAP CPI Debug Logging: Detailed Processing Information
The Debug log level records detailed information for all steps during message processing. SAP describes Debug as a high-resource-consuming option and recommends using it primarily in development or test environments. In the Cloud Foundry environment, Debug has a fixed 24-hour activation period. Once the period expires, the integration flow returns to the log level configured before Debug was enabled. Debug provides detailed processing and step information, but it does not provide the message content, including payload, header, and properties. That distinction is important when deciding which log level to use for a production incident.
SAP CPI Trace Logging: Payload and Message Content
Trace goes further than Debug when the investigation requires message content. When Trace is enabled, SAP Cloud Integration can record the payload, headers, and properties as the message moves through the integration flow. This makes Trace the relevant diagnostic level when an engineer needs to examine how message content changes between processing steps. The default Trace activation period is 10 minutes. After that period, Trace automatically expires and the previous log level is restored. The captured trace data has a separate retention period. SAP documents a default of 60 minutes for trace data in Cloud Foundry.
That means three different concepts should not be treated as one:
| Logging mechanism | What it provides | Default period |
|---|---|---|
| Debug | Detailed processing and step information | 24-hour activation in Cloud Foundry |
| Trace | Detailed processing information plus message content | 10-minute activation |
| Trace data | Captured trace information available for investigation | 60 minutes |
| Message Processing Log | Structured processing information | 30 days in Cloud Foundry |
The activation period and retention period are different. Enabling Trace for 10 minutes does not mean the resulting trace data disappears immediately when Trace is switched off.
SAP CPI's 1 GB MPL Attachment Limit
The 1 GB limit applies to MPL attachments written over a 24-hour period, not to the total amount of payload data that SAP Cloud Integration can process or store. MPL attachments can be created during runtime, including through the Script API. They can be useful when an integration needs additional diagnostic information or payload-related evidence beyond the standard message processing log. SAP documents a limit of 1 GB of MPL attachments written per 24 hours. Once the limit is reached, further MPL attachments are not stored until the amount written during the preceding 24 hours falls below the threshold.
What Happens When the 1 GB MPL Attachment Limit Is Reached?
The limit functions as a safeguard against excessive attachment storage. If an integration generates large payload attachments at high volume, the available attachment capacity can be consumed quickly. This is one reason SAP recommends using payload attachments selectively rather than writing every production payload to the MPL.
The practical implication is straightforward:
Do not treat MPL attachments as a general-purpose long-term payload repository.
Use them deliberately for diagnostics, while defining a separate persistence or archiving strategy for business data that must remain accessible for longer periods.
SAP CPI Logging Limits: Log Level vs. MPL Retention vs. Storage
Several SAP CPI limits are often described together even though they govern different types of data.
How Long Does SAP CPI Retain Message Processing Logs?
For Cloud Foundry, SAP documents a 30-day retention period for Message Processing Logs. SAP also documents 30 days for MPL attachments. Trace data has a much shorter 60-minute retention period. This creates an important operational distinction:
- MPL retention: 30 days
- MPL attachment retention: 30 days
- Trace data retention: 60 minutes
- Debug activation: 24 hours
- Trace activation: 10 minutes
These values should not be summarized as a single "SAP CPI log retention" period. The data type determines how long the information remains available.
Can SAP CPI Log Retention Be Extended?
Longer retention should be designed around the type of information that needs to be preserved. For Cloud Foundry, SAP provides data-archiving capabilities for supported monitoring and message data, subject to the applicable service plan and configuration. Persistent storage mechanisms can also be used when an integration requires access to message content after normal monitoring data is no longer available. The appropriate approach depends on whether the requirement is:
- short-term troubleshooting,
- operational message recovery,
- audit-related message persistence,
- long-term business-data retention, or
- centralized monitoring and analysis.
The key architectural decision is therefore not simply "increase the log retention." It is deciding which data needs to remain available, for how long, and where it should live.
Can the SAP CPI Payload Logging Limit Be Increased?
The 1 GB figure should not be described as a universal payload-storage limit. It is specifically the documented limit for MPL attachments written within a 24-hour period. SAP's documentation also describes environment-specific storage and quota considerations, so increasing or changing capacity depends on the specific Cloud Integration environment and service configuration. For that reason, production architectures should avoid relying on MPL attachments as the primary mechanism for storing every payload.
How to Extend SAP CPI Payload and Log Retention
When standard monitoring is insufficient for an operational or compliance requirement, SAP Cloud Integration provides several mechanisms that serve different purposes.
Using the Persist Step for Longer Payload Retention
The Persist step stores message content so that it can be accessed and analyzed after message processing. For Cloud Foundry, SAP documents a 90-day retention period for data stored using the Persist step. This is separate from the 30-day retention of standard Message Processing Logs. Persistence is therefore better suited to scenarios where the message itself needs to remain available beyond the normal monitoring window. It should still be used selectively. Persisting every high-volume production message can create unnecessary storage and data-management requirements.
Using Data Store for Message Persistence
The Data Store operation can also retain message content for subsequent processing or analysis. In Cloud Foundry, SAP documents a default Data Store retention period of 30 days, configurable by the integration developer up to a maximum of 180 days. This makes Data Store useful when message persistence is part of the integration design rather than simply a diagnostic requirement.
Using SAP Archiving for Longer-Term Requirements
For longer-term retention requirements, SAP Cloud Integration provides archiving capabilities in the Cloud Foundry environment, subject to the applicable service plan and configuration. Archiving should be considered separately from Trace and Debug. Those log levels are diagnostic mechanisms, whereas archiving is part of a broader data-retention strategy.
The design should establish:
- Which messages need to be retained.
- Whether payloads or only processing metadata are required.
- How long the data must remain accessible.
- Who needs access to it.
- Whether the data contains sensitive or regulated information.
- How the retained data will be searched and retrieved during an incident.
Why SAP CPI Sender and Receiver Fields Are Blank
A common monitoring problem is seeing incomplete business context in the Message Processing Log. SAP documentation states that fields such as SenderId, ReceiverId, and MessageType are displayed when the corresponding values have previously been defined as header properties. This means the absence of a sender or receiver value does not necessarily indicate a monitoring failure. The required metadata may simply not have been populated in the integration flow.
How to Populate Monitoring Metadata in an iFlow
Teams should define consistent monitoring metadata as part of the integration-flow design. Depending on the monitoring requirement, useful identifiers can include:
- Sender ID
- Receiver ID
- Message type
- Application ID
- Correlation ID
- Business document identifier
SAP Cloud Integration's Message Processing Log supports custom header properties, and the platform's documentation describes sender, receiver, and message type fields as values that can be surfaced when defined appropriately. The objective is not to add every possible field to every message. It is to ensure that an engineer can identify the affected business flow without reconstructing the context manually from the integration-flow definition.
What SAP CPI Teams Should Configure Before an Incident
Logging strategy is most useful when it is designed before the incident occurs.
Define the Required MPL Metadata During iFlow Development
Decide which identifiers an operations team needs to search and correlate messages. For example, a B2B integration may require sender, receiver, message type, application ID, and a business correlation identifier. These fields should be part of the integration design rather than added only after a production incident.
Define the Payload Retention Strategy Before Production
Not every payload needs the same retention period. A practical strategy can separate:
- Incident diagnostics: Debug or Trace when needed
- Routine operational monitoring: Message Processing Logs
- Message persistence: Persist or Data Store where required
- Long-term retention: Archiving or an appropriate external data store
- Centralized operational analysis: External monitoring or observability architecture where appropriate
This avoids treating the standard MPL as the only place where production evidence can exist.
Choose Debug, Trace, or Persistence Based on the Failure Scenario
The distinction between Debug and Trace matters. Use Debug when detailed processing and step-level information is needed without message content. Use Trace when the investigation requires the payload, headers, or properties moving through the flow. Use persistence mechanisms when message content must remain accessible beyond the short diagnostic window. SAP recommends using Debug and Trace primarily in development or test environments because of their resource consumption.
What SAP CPI Logging Limits Mean for Production Monitoring
Standard SAP Cloud Integration monitoring can provide the information required for many operational scenarios, but its diagnostic mechanisms operate within defined windows and storage rules. The practical issue for enterprise teams is not simply the existence of these limits. It is whether the monitoring architecture provides enough information when a production incident occurs. A useful production monitoring design should answer four questions:
What failed? The Message Processing Log should identify the processing status and relevant execution information.
Where did it fail? Step-level information, correlation identifiers, and appropriate monitoring metadata help isolate the affected stage.
What data was processed? Trace or deliberately persisted message content may be required when the standard MPL does not contain enough information.
Can the message be recovered or reprocessed? That requirement needs to be addressed through the integration design and operational tooling rather than assumed to be provided by standard logging.
For enterprises that need monitoring capabilities beyond standard SAP Cloud Integration monitoring, Tarento's iVolve enhanced monitoring through Integration Inspector is designed to extend runtime visibility, including monitoring capabilities beyond the standard platform experience.
Explore iVolve enhanced monitoring
The article on integration firefighting covers the operational problem in greater depth, including enhanced monitoring, error reporting, restart capabilities, and search across sender, receiver, message type, and application ID.
Frequently Asked Questions
How long does SAP CPI Trace last?
The default Trace activation period is 10 minutes. Trace data is retained for a default period of 60 minutes in Cloud Foundry. These are separate limits.
How long does SAP CPI Debug last?
In the Cloud Foundry environment, the Debug log level has a fixed 24-hour activation period. Debug provides detailed processing information but does not provide message content such as payload, headers, and properties.
Does SAP CPI Debug capture the payload?
No. SAP distinguishes Debug from Trace on this point. Debug provides detailed processing information, while Trace additionally captures message content, including payload, headers, and properties.
How long does SAP CPI retain Message Processing Logs?
For Cloud Foundry, SAP documents a 30-day retention period for Message Processing Logs. MPL attachments are also documented with a 30-day retention period.
Can SAP CPI retain messages for longer than the standard MPL period?
Yes. SAP Cloud Integration provides mechanisms such as the Persist step, Data Store, and supported archiving capabilities for different retention requirements. In Cloud Foundry, SAP documents 90 days for Persist, configurable Data Store retention up to 180 days, and separate archiving capabilities subject to the applicable service configuration.
Why are sender and receiver fields blank in SAP CPI monitoring?
Sender and receiver identifiers are displayed in the MPL when the corresponding values have been defined as header properties. If those values are not populated as part of the integration flow, the monitoring view may not contain the business context an operations team expects.
Conclusion
SAP CPI logging limits are easier to manage when each mechanism is treated according to its purpose.
Debug provides detailed processing information and has a 24-hour activation period in Cloud Foundry. Trace captures message content but has a default 10-minute activation period and 60-minute trace-data retention. Message Processing Logs have a longer 30-day retention period, while MPL attachments are subject to a separate 1 GB-per-24-hour write limit.
For longer retention, teams can use persistence mechanisms such as Persist and Data Store, or appropriate archiving capabilities depending on the requirement and environment.
The larger architectural question is what information an operations team needs when an integration fails. If that requirement is defined before production, logging, persistence, monitoring metadata, and recovery mechanisms can be designed together rather than reconstructed during an incident.
For enterprises that need monitoring capabilities beyond standard SAP Cloud Integration monitoring, iVolve's Integration Inspector provides enhanced monitoring as part of Tarento's broader integration modernization framework.
SAP Integration Suite Git Version Control: GitHub, iFlows, and Backup
