|
Key takeaways
|
TABLE OF CONTENTS
- What RISE with SAP monitoring covers, and what it leaves to you
- Who monitors what under RISE with SAP
- The black box problem: what you lose access to
- SAP Cloud ALM vs. purpose-built SAP monitoring
- Seven monitoring strategies for RISE with SAP
- SLA verification: proving the 99.7% number
- Integration monitoring across Cloud ERP and BTP
- How Avantra closes the visibility gap
- Frequently asked questions
The “black box” problem in
Avantra solves this challenge by providing purpose-built, application-layer monitoring that tracks business processes, custom code, and external integrations without requiring underlying infrastructure access.
While the move to the cloud shifts operational boundaries, your team still owns the application layer, configuration, performance tuning, and compliance.
For teams mid-transition, the gap doubles. You run traditional ERP and Cloud ERP side by side for a year at minimum, often longer for complex estates. Two toolsets. Two escalation paths. No single view of the SAP estate at the exact moment you need one most.
|
“We had thousands of performance tickets a year. With Avantra, business users could self-check. We saved Basis time and eliminated entire ticket categories.” Darko Rozac, Principal Software Architect, Shutterfly. Read the Shutterfly case study |
What RISE with SAP monitoring covers, and what it leaves to you
The appeal of Cloud ERP centres on a fully managed service with less day-to-day technical work for your team. Private Cloud ERP works differently. It is a hybrid model. Customers keep significant operational responsibility at the Basis and business application layers while giving up hardware access.
Patching schedules, custom code monitoring, interface health, and compliance evidence stay with you. The split between what SAP manages and what you manage is documented, but the document runs past 50 pages of spreadsheet. Many teams read it only after the first incident.
Several organisations add Basis headcount during the transition rather than reducing it. The work does not disappear. It changes shape.
Responsibility split at a glance
| Layer | SAP manages (Private Cloud) | You manage |
|---|---|---|
| Hardware, storage, network | Full ownership, covered by infrastructure SLA | No access, no telemetry |
| Operating system | Patching and availability | No shell access, no OS-level metrics |
| Database (HANA) | Backup, base availability | Query performance, growth, application impact |
| SAP Basis layer | Kernel and release baselines | System parameters, transports, jobs, users |
| Application and custom code | Nothing | Configuration, ABAP, performance tuning, testing |
| Interfaces and business processes | Nothing by default | IDocs, RFCs, queues, batch chains, SLA evidence |
Deciding between deployment models first? Compare the options in S/4HANA or RISE with SAP before you commit to an operating model.
Who monitors what under RISE with SAP
The responsibility split above shows who owns each layer. Monitoring follows a different line. Use this table to agree who watches what, who holds the evidence, and who acts when something fails.
| Area | SAP | The customer | Where Avantra helps |
|---|---|---|---|
| Infrastructure and network availability | Runs hardware, storage, data centre and network. Reports availability against the infrastructure SLA. | Has no infrastructure telemetry. Tracks when an outage hits SAP systems and the business. | Records SAP system availability from the application layer, with timestamps you own. |
| OS and database | Patches the operating system. Runs HANA backups and base database availability. | Owns query performance, data growth and the impact on applications. | OS-level checks on the SAP-managed host are not available. Avantra flags application-layer symptoms, such as slow dialog response, for you to raise with SAP. |
| Application availability and business processes | Not covered unless you contract Cloud Application Services separately. | Owns availability of business processes, configuration and custom code. | Runs SAP-level checks agentlessly, as often as every five minutes, so you report availability at the process level. |
| Batch jobs and interfaces | Nothing by default. | Owns background jobs, IDocs, RFCs, queues and batch chains. | Monitors jobs and interfaces as objects with their own thresholds, and routes alerts into ServiceNow. |
| SLA evidence for service reviews | Reports infrastructure availability against its own SLA. | Holds its own timestamps and process-level availability. | Keeps pass or fail evidence from automated daily checks. Pulls Cloud ALM health metrics in as checks. |
| Incident handoff to SAP | Resolves infrastructure incidents raised as SAP for Me support cases. | Isolates the fault at the application layer, opens the case with evidence and tracks it to closure. | AIR can generate a root-cause report on a failing check. Alerts on open SAP for Me cases for systems mapped through the Cloud ALM integration. |
Security responsibilities sit outside this table and follow their own split.
The black box problem: what you lose access to
You keep the ABAP layer. SM37 for background jobs, ST22 for dumps, SM21 for the system log, SM12 for lock entries, SM58 and SMQ1 or SMQ2 for queues, WE02 for IDocs, ST03N for workload. Those transactions still open.
What disappears is everything beneath them:
- OS shell access. No sapcontrol from the command line, no trace file inspection under /usr/sap, no live process view.
- Database administration. HANA cockpit and DBACOCKPIT rights are restricted, so expensive statement traces and index analysis need a ticket.
- Infrastructure telemetry. Storage latency, hypervisor contention, and network path metrics sit with the provider.
- Correlation. ST06 style OS data no longer lines up with your application metrics, so you cannot tie a slow dialog step to a noisy neighbour or a storage event.
The result is a diagnostic dead end. A dialog response time doubles, ST03N confirms it, and the next step is a support ticket with no evidence attached. Teams report investigation cycles stretching from hours into days on performance and interface issues, purely because root cause analysis stops at the application boundary.
Some incidents resolve as infrastructure or network faults inside the managed estate. Customers had no way to detect those faults or prove them. Setting support expectations early matters. Investing in application-layer observability matters more.
Related reading: agent-based vs. agentless SAP monitoring explains which collection method fits restricted environments.
SAP Cloud ALM vs. purpose-built SAP monitoring
Cloud ALM is included with your subscription and covers standard Cloud ERP health well: SAP-delivered scenarios, business process monitoring, and integration tracking for clean, greenfield implementations. It’s the right starting point for a tenant with little custom code and few external systems to account for.
Coverage naturally narrows as the estate gets more complex. Cloud ALM is built around the SAP-delivered scope, so hybrid landscapes carrying legacy on-premises systems, non-SAP databases (Oracle, SQL Server, SQL Anywhere), heavy custom ABAP or Z-code, and multi-year migrations typically need it complemented with purpose-built SAP monitoring for automated daily checks with pass/fail evidence, custom-code checks, automated remediation, application-layer SLA evidence for the business, a single hybrid pane of glass across cloud and on-premises, and native ITSM workflows like ServiceNow.
Teams running a mixed estate through a transition generally run both together: Cloud ALM for the Cloud ERP core, and a broader platform for everything Cloud ALM’s scope doesn’t reach.
Seven monitoring strategies for RISE with SAP
Use these seven strategies as the operating model for Cloud ERP observability. Each one addresses a specific consequence of losing infrastructure access.
- Monitor at the application layer with SAP-native checks. Batch jobs, dumps, locks, update errors, and queue depth are visible through the ABAP layer. Automate their collection instead of running transactions by hand each morning.
- Establish a baseline before the migration. Capture response times, job runtimes, and interface volumes on the current systems. Without a baseline, post-migration complaints turn into opinion.
- Verify SLA compliance independently. Measure availability from the application layer on your own schedule. Bring evidence to the provider rather than a description of symptoms.
- Track integrations separately from the core system. IDocs, RFC destinations, queues, and BTP services fail independently of ERP availability. Monitor each endpoint with its own thresholds.
- Automate configuration drift detection. Provider-side changes and transport activity alter system parameters over time. Automated comparison against a known-good state catches drift before it produces an incident.
- Run one platform across cloud and on-premises. Two toolsets during a transition means two alert streams and no correlation. A single platform preserves continuity through the whole programme.
- Automate daily checks and free the Basis team. Manual health checks consume hours per day per engineer. Automation converts that time into migration work and cuts detection time on real faults.
Point four matters more than teams expect. See monitoring SAP hybrid cloud deployments and the challenges of SAP’s hybrid ERP world for the operational detail.
What to monitor at the application layer
| Object | What to watch | Why it matters in Cloud ERP |
|---|---|---|
| Batch jobs (SM37) | Failures, runtime drift, chain dependencies | Job overruns hit period close with no OS view to explain them |
| IDocs (WE02) | Stuck statuses, backlog growth, partner errors | Interface failures are invisible in infrastructure SLAs |
| RFC and queues (SM58, SMQ1) | Connection errors, queue depth, retries | Cross-system calls break during provider maintenance windows |
| Dumps and system log (ST22, SM21) | Frequency, new patterns after transports | Earliest signal of a change-related fault |
| Custom code | Runtime of Z-programs, expensive statements | Fully your responsibility, outside SAP scope |
| Business process availability | End-to-end transaction success | Answers “can we do business today” better than uptime |
SLA verification: proving the 99.7% number
Private Cloud ERP offers a standard SLA around 99.7% and enhanced options with higher targets and faster response commitments. Both apply to the managed infrastructure layer: hardware, virtualisation, and network services.
Neither extends to the SAP application layer unless you contract Cloud Application Services separately. Business processes, configuration, and custom developments sit outside the number.
A system reporting 99.7% infrastructure availability still delivers a failed month end if the payment run aborts twice. Measure what the business feels. Report availability at the process level, hold your own timestamps, and use them in service reviews.
For SLA design guidance, read setting the right SAP SLA to ensure business continuity.
Running service reviews with your own evidence
A service review built on SAP’s report shows SAP’s view. Bring three things of your own:
- Timestamps. Record when a check first failed, when you raised the case, and when service returned. Your record starts when the business felt the problem, not when the ticket was logged.
- Process-level availability. Report the payment run, order intake and month-end jobs next to infrastructure uptime.
- Open SAP support cases. Track every open case and service request per system, with its age and business impact.
Avantra covers the third point. Once a system is mapped through the Cloud ALM integration, Avantra can alert on open SAP for Me support cases and service requests for that system.
Integration monitoring across Cloud ERP and BTP
SAP systems rarely run alone. Warehouse platforms, banking interfaces, tax engines, CRM, and BTP services all exchange data with ERP. Those dependencies survive the move to Cloud ERP unchanged, and the oversight requirement survives with them.
Monitor each interface as a first-class object with its own thresholds: message volume against expected range, error rate, latency, and certificate expiry. An interface degrading quietly for three days costs more than an outage detected in ten minutes.
How Avantra closes the visibility gap
Avantra monitors the application layer of RISE with SAP systems agentlessly, so customers hold their own evidence for SLA reviews and incident handoffs to SAP.
Avantra is purpose-built for SAP operations, not a generic APM tool pointed at an SAP system. An Avantra agent on your own network connects to the SAP application layer, with no access to the SAP-managed host. Almost all SAP-level checks work this way. OS-level checks on the host do not. Monitoring checks run as often as every five minutes.
The SAP Cloud ALM integration is generally available in Avantra 26H2. It maps Cloud ALM systems to Avantra systems and pulls Cloud ALM health metrics in as checks.
For tickets to SAP, Avantra AIR can generate a root-cause report on a failing check, so the case reaches SAP with evidence attached.
- Deep application-layer visibility into batch jobs, IDocs, RFCs, and custom development without infrastructure-level access.
- Automated daily checks replacing manual transaction rounds, with pass or fail evidence retained for audit and service reviews.
- Configuration drift detection with automatic alerting, keeping monitoring consistent as systems change.
- Intelligent alerting and root cause analysis at the application layer, so tickets to the provider carry evidence rather than symptoms.
- ServiceNow integration through certified connectors, routing alerts into existing incident workflows.
- One platform across on-premises and cloud estates, giving Basis teams operational transparency through the entire transition.
Teams running Cloud ERP alongside legacy systems typically start with the Avantra Cloud Edition for RISE with SAP or the Avantra Observability Edition. Estates needing automated remediation and enterprise workflows move to the Avantra Enterprise Edition. See how the pieces fit on the RISE with SAP and Avantra page, or review SAP system monitoring automation.
Frequently asked questions
What monitoring can customers actually do in RISE with SAP Private Cloud?
You monitor everything at and above the SAP application layer: batch jobs, IDocs, RFC destinations, queues, dumps, system logs, custom code runtime, user activity, and business process availability. Operating system shells, database consoles, and infrastructure telemetry stay with the provider, so application-layer tooling carries the full diagnostic load.
What does SAP manage vs. what remains the customer’s responsibility?
SAP manages hardware, virtualisation, network, operating system patching, and base database availability under the infrastructure SLA. You keep system health, performance tuning, configuration, transports, custom developments, interface monitoring, and compliance evidence at the Basis and application layers.
How is RISE with SAP monitoring different from on-premises SAP monitoring?
On-premises, application metrics and OS or database metrics correlate in one view, so root cause analysis runs end to end. In Private Cloud ERP the lower layers are abstracted away. Monitoring shifts to application-layer signals plus independent SLA verification, and unresolved issues escalate through support tickets rather than direct investigation.
Is SAP Cloud ALM enough for Private Cloud monitoring?
For a greenfield Cloud ERP tenant with little custom code and few external interfaces, Cloud ALM covers standard monitoring. Hybrid estates with legacy SAP systems, non-SAP databases, heavy custom code, or complex integration chains need broader coverage, automated daily checks, and remediation Cloud ALM does not provide.
What happens when there is a performance issue and my team cannot access the infrastructure?
You isolate the problem at the application layer first: workload analysis, job runtimes, lock waits, queue depth, and expensive statements. Then you raise a ticket with timestamps and evidence attached. Teams with automated application-layer monitoring resolve or correctly escalate faster because they arrive with data instead of a description.
What integrations need to be monitored in a RISE with SAP environment?
Monitor every interface leaving the ERP system: IDoc partners, RFC destinations, qRFC and tRFC queues, BTP services, cloud connector links, banking and tax interfaces, and non-SAP applications exchanging data. Track message volume, error rate, latency, and certificate expiry for each one.
Does the 99.7% Cloud ERP SLA cover my business processes?
No. The standard SLA of approximately 99.7% covers the underlying hardware, virtualisation, and network services. Application-layer availability, business processes, and custom developments fall outside it unless you contract Cloud Application Services options. Verify process availability independently.
Why do some organisations need more Basis staff during a Cloud ERP transition?
Basis teams run two environments at once, learn a new toolset for Cloud ERP, and keep the existing on-premises estate running, all without a single point of control. Responsibilities treated as included in standard cloud services remain customer-owned in Private Cloud ERP. Automating daily checks is the fastest way to reduce the load.
Who is responsible for monitoring SAP systems under RISE with SAP?
SAP monitors the infrastructure it runs, and the customer monitors everything at and above the SAP application layer. SAP covers hardware, network, the operating system and base database availability. Your team owns application availability, business processes, batch jobs, interfaces, and the evidence you take into service reviews.
How do companies hold SAP accountable to the RISE with SAP SLA?
They bring their own evidence to service reviews instead of relying on SAP’s report alone. That evidence covers timestamps for each incident, availability measured at the process level, and a list of open SAP support cases with their age and impact. The SLA covers the managed infrastructure, so your records need to show when an infrastructure fault hit a business process, and for how long.
What monitoring governance should enterprises keep under RISE with SAP?
Keep ownership of application-layer monitoring, incident handoff to SAP, and SLA evidence. In practice that means a documented monitoring split with SAP, defined checks and thresholds for jobs, interfaces and business processes, a named owner for raising and tracking SAP support cases, and a regular service review run on your own data. Revisit the split whenever your contract or landscape changes.
Trust, but verify
Cloud ERP delivers scalability and a faster innovation cycle. The value holds only while the system stays available to the business. Availability at the infrastructure layer is the provider’s promise. Availability at the application layer is your evidence to produce.
Talk to an Avantra expert about monitoring your Cloud ERP and on-premises SAP systems from one platform, or explore the Avantra platform. Book a demo.