Understanding SAP SLAs: Availability, Risk & What You’re Really Getting

Like most of us who pay a subscription fee to access our favorite online services and applications without disruption (streaming platforms for example), organizations have an expectation of availability at all times for the Cloud services they invest millions in each year. Business’s rely on system availability for business continuity and performance capability. However, a cloud system’s availability can be vulnerable to everything from human error, infrastructure to external shock.   

When SAP and other environments become unavailable – the impacts can be catastrophic: lost productivity, delayed transactions, customer disruption, and financial risk. Although not commonly thought about, this is why Service Level Agreements (SLA’s), Disaster Recovery (DR) options and defined Recovery Time Objectives (RTO) are essential to SAP strategy and consumer confidence.  

In practical terms, an SLA defines the level of service the provider commits to deliver, Disaster Recovery describes how services will be restored after a major disruption, and a Recovery Time Objective sets the maximum acceptable time to recover critical services following a declared disaster. Together, these three measures help organizations align technical recovery capabilities with business continuity requirements – this article will provide a high-level introduction to SLA’s.  

SAP Service Level Agreements (SLAs) – Do You Receive What Is Promised? 

Deal structure, environment and cloud offering all impact the defaulted and additionally available add-on’s for system availability. The table below breaks down the SLA for different deployment scenarios. 

SAP improved its Production System Public Cloud SLA uptime to 99.9% (previously 99.7%) across the entire Public Cloud portfolio in 2024, with BTP critical services elevated to 99.95% in 2021. 

What Does 99.7% Availability Actually Mean?

99.7% equates to approximately 2.2 hours of permissible downtime per month, or over 26 hours per year. By comparison, S/4HANA Public Cloud and select BTP services commit to 99.9% & 99.95% uptime respectively – roughly 43 & 22 minutes of permissible downtime per month.  

What doesn’t count as downtime (exclusions): 

The SLA figures that are marketed do not take into consideration specific exclusion factors, some of which are listed below and are also reflected in individual Cloud Agreements: 

• Customer Configuration or Workload Spikes 
• Failures in customer managed third-party integrations 
• Planned Maintenance 
• Force Majeure – events beyond either party’s control that prevent SAP meeting its availability commitments. Typical examples include natural disasters, war, civil unrest, government action, pandemics, and major infrastructure failures (data centres). 
• Coverage exclusion extended to: SAP AI model training (applicable modules only). 

SAP RACI Framework, 3rd Party Hyperscalers and Service Credit Refund Challenges:

As part of the embedded RACI (Responsible, Accountable, Consulted & Informed) Framework agreement now seen in RISE implementations, agreements are subject to a three-party responsibility model – in the department of SLAs this includes yourself as the customer, SAP and any accompanying 3rd party Hyperscaler (if applicable). System outage incidents often span multiple layers, which can lead to unclear accountability and delayed resolution. In practice, this means that when something goes wrong, an extended time can be taken in assuming who takes responsibility for the loss of business capability before the fix itself can actually happen.  

In some instances 3rd party infrastructure outage is denoted in SAP Contracts as an applicable Force Majeure event suggesting that the ability to successfully apply for credit in the event of third-party hosted Hyperscaler infrastructure outages may be unrewarding.  

SAP and other vendors typically apply a standard credit cap which is usually between 10 and 15% of the monthly subscription value, meaning even extended production outages can generate limited compensation. On top of that, SLA compensation is typically limited to service credits rather than broader liability – so any compensation received will either be through credit towards future payment of the service or through refund, subject to the subscription period closing.  

Inclusion of SLA and Recovery Services are no doubt crucial to business continuity, but enhanced options additionally increase the cost of the estate. As SLA, DR and RTO are metricised as a % of the estate value, the importance of having your proposal checked and optimized beforehand is therefore crucial.  

At JNC, our extensive software advisory experience, disciplined challenge of commercial terms such as SLAs, and access to real-world benchmarking proposal data ensures your proposal is qualified and your investment delivers maximum value.