When a project team signs up for RISE with SAP, someone usually says "SAP manages the infrastructure." That phrase is accurate and produces a consistent misunderstanding: that infrastructure includes the monitoring responsibility for what runs on that infrastructure. It does not. The boundary between what SAP manages and what the customer remains responsible for is sharper and less favorable to the customer than the phrase suggests.
This guide maps that boundary precisely, explains what it means operationally for the monitoring layer, and covers how to connect monitoring to a RISE environment in a way that closes the gaps the shared responsibility model leaves open.
What SAP manages in RISE and what that means for monitoring
RISE with SAP bundles S/4HANA Cloud Private Edition hosting, SAP BTP, and managed infrastructure into a subscription. SAP, together with the underlying hyperscaler, manages the physical and virtual infrastructure: compute, storage, networking, operating system patching, HANA cluster high availability configuration, database administration, and platform-level incident response when infrastructure components fail.
What SAP's management scope does not include is operational visibility into the application running on that infrastructure. SAP's monitoring covers whether the platform is available and whether the HANA service is running. It does not cover whether background jobs completed on time, whether IDocs are accumulating errors, whether dialog response times are within SLA, or whether update tasks are failing silently. These conditions are invisible to SAP's monitoring and entirely within the customer's operational scope.
The practical consequence is straightforward: moving to RISE with SAP does not reduce the monitoring work the customer needs to do at the application layer. It eliminates the infrastructure monitoring that the customer was doing before, which is the smallest and least operationally significant part of SAP monitoring. The application layer monitoring, which is where most SAP incidents originate, remains the customer's responsibility in full.
The shared responsibility boundary: a clear view
The table below maps the specific responsibilities in a RISE with SAP environment. The distinction is not a matter of interpretation: SAP's contractual commitment covers platform availability. Application health is customer-owned.
| SAP manages in RISE | Customer still owns |
| Hyperscaler infrastructure (compute, storage, network) | Background job scheduling and outcome monitoring |
| HANA cluster HA configuration and failover | HANA application performance (M_* views) |
| OS patching and kernel updates | IDoc, RFC, and API interface health |
| SAP platform availability SLA | ABAP short dumps and update task failures |
| Network connectivity to hyperscaler region | BTP extension performance and Integration Suite flows |
| Platform-level incident response (infrastructure down) | Business process completion SLOs |
| Database administration and HANA platform services | Custom ABAP code quality and authorization design |
| Watch out: The RISE SLA covers infrastructure and platform availability. It does not cover application response time, batch job success rates, interface processing times, or business process completion windows. An organization that relies on RISE to cover these conditions will discover the gap when it matters most: during an incident investigation when SAP support confirms the platform is healthy and the problem is in the application layer. |
What you still own: the monitoring scope that does not transfer
Application-layer metrics
Every application-layer metric that mattered before RISE still matters in RISE. Dialog response time by transaction code, work process utilization per instance, update task queue health, background job success rates, and ABAP short dump frequency are all customer-owned monitoring responsibilities. The transactions SM50, SM66, SM37, SM13, and ST22 are available in RISE, and the data they contain is as relevant as it was on-premise. SAP work process monitoring and SAP background job monitoring both apply in RISE without modification to the monitoring approach.
HANA application metrics remain customer-owned even though SAP manages the HANA platform. The system views in the SYS schema, M_MEMORY_OVERVIEW, M_DISK_USAGE, M_BACKUP_CATALOG, M_DELTA_MERGE_STATISTICS, M_EXPENSIVE_STATEMENTS, are accessible to a customer-provisioned monitoring database user in RISE. SAP monitors HANA as a service. The customer monitors HANA as a database hosting their application data. These are different monitoring objectives that require different metrics. SAP HANA database monitoring covers the full set of application-layer HANA metrics that remain the customer's responsibility in RISE.
Business process outcomes
SAP does not know whether a specific batch job that ran on the RISE-hosted system was supposed to complete by 06:00 or whether the output it produced matches the business expectation. Those are application and business requirements that SAP has no visibility into. Business process SLOs, the commitments to the business about what the system will deliver and when, are entirely outside SAP's scope in RISE.
This is where the gap between a 99.9% platform availability SLA and an organization's actual continuity requirements becomes concrete. The platform can be available at 100% while a batch job fails, an interface stops processing, and a month-end close deadline is missed. SAP's SLA is met. The business SLA is not. The only party that can monitor and respond to the business process layer is the customer.
BTP extensions and integration layer
BTP is included in the RISE bundle, but extensions built on BTP are customer-owned code running on SAP-managed infrastructure. The same responsibility split applies: SAP manages the BTP platform. The customer owns what runs on it. Integration Suite flows, custom BTP applications, and API endpoints built as S/4HANA extensions have their performance, error rates, and availability monitored by the customer. The SAP integration hub monitoring guidance is directly applicable to BTP-hosted integration scenarios in RISE.
How monitoring connectivity works in RISE with SAP
RFC connection to the ABAP application layer
Connecting a monitoring platform to a RISE-hosted S/4HANA system via RFC follows the same process as connecting to any other SAP system. A dedicated monitoring technical user is created in the production client, assigned the appropriate authorization profile for read-only monitoring access, and an RFC destination pointing to the monitoring collector is configured in SM59. No infrastructure access is required and no SAP-side software needs to be installed.
This is precisely the agentless approach. RISE imposes no special constraint on RFC-based monitoring collection beyond requiring that the monitoring user has appropriate authorization. SAP agentless monitoring architecture covers the authorization setup in detail. The same technical process that works for on-premise S/4HANA works for RISE with SAP Private Edition.
HANA SQL access in RISE
A monitoring database user in HANA requires specific system privileges: MONITORING and CATALOG READ are the core requirements. In RISE environments, creating this user follows SAP's documented process for customer database users, which is different from the full DBA access available in customer-managed HANA installations. The monitoring tool connects via JDBC, executes read-only SQL against system views, and collects the application-layer metrics the customer is responsible for monitoring.
There is no SAP restriction on customers connecting monitoring tools to their RISE-hosted HANA instance for application-layer data collection. SAP does restrict infrastructure-level access: direct SSH to the OS layer, HANA administration beyond the customer's scope, and changes to SAP-managed configuration. These restrictions do not affect application-layer monitoring connectivity.
| Note: In RISE with SAP Public Edition, the monitoring scope is more constrained than in Private Edition. Public Edition uses a highly standardized configuration where customers have less ability to modify system parameters or install custom monitoring configurations. If you are evaluating Public Edition, verify with SAP what specific monitoring connectivity and access is available before assuming Private Edition capabilities apply. |
Monitoring gaps that RISE customers discover after go-live
The monitoring gaps specific to RISE follow a consistent pattern: capabilities that were present in the on-premise model, often taken for granted, that require explicit setup in the RISE model because the assumption that SAP handles monitoring has been applied too broadly.
The most common gap is background job monitoring. Teams that move to RISE assume that SAP will alert them if something goes wrong with the system. They are correct for infrastructure-level events. They are incorrect for batch jobs. A Tier 1 batch job that fails at 04:00 on a RISE-hosted system generates no alert to the customer unless the customer's monitoring platform is configured to detect it. SAP support will confirm, when called, that the platform is healthy. The job failure is an application event, not a platform event.
The second gap is interface monitoring. IDocs accumulating errors in BD87, qRFC queues building up in SMQ1, RFC destinations pointing to systems that have changed connectivity, SSL certificates expiring on Integration Suite connectors: all of these are application-layer events that SAP's RISE monitoring does not cover and that produce no automatic alert. The SAP interface monitoring guide applies directly to RISE environments. The monitoring tool is connecting to the same application layer via RFC regardless of where the hardware sits.
The third gap is HANA application performance. SAP monitors HANA for platform stability. Memory consumption approaching the allocation limit is a customer-owned monitoring responsibility that SAP will not proactively alert the customer about unless it reaches the point of a platform-level event. The practical consequence is the same as in on-premise HANA environments: without monitoring, the first indication of HANA memory pressure is often an unplanned database stop. The S/4HANA go-live readiness monitoring guide covers what to instrument before the first production workload runs in RISE, regardless of whether the system is freshly migrated or new.
RISE with SAP changes who is responsible for infrastructure. It does not change what needs to be monitored at the application layer or who is responsible for monitoring it. The customers who are best prepared for this are the ones who read the shared responsibility model carefully before go-live, connected application-layer monitoring before the system went live, and did not confuse "SAP manages the infrastructure" with "SAP manages the monitoring."
The customers who are least prepared are the ones who discover the monitoring gap during the first post-go-live incident, when SAP support confirms the platform is healthy and the investigation of the actual problem has to start from scratch because no application-layer monitoring was in place.
Redpeaks connects to RISE with SAP environments via standard RFC and HANA SQL with no infrastructure access required. The same monitoring coverage available on-premise is available in RISE. See the RISE with SAP monitoring coverage.
