The SLA says 99.9% availability. Last month the system was available for 99.92% of measured time, technically exceeding the commitment. During the remaining 0.08%, the financial close batch run failed to complete by its agreed deadline. The SLA dashboard showed green. The finance director received the same report two hours late and missed the board meeting deadline. The SLA was met. The commitment was not.
That specific disconnect, between what monitoring reports and what the business actually agreed to receive, is the operational problem that SLA observability is designed to solve. It requires measuring at the layer where commitments were made, not at the layer where data is easiest to collect.
Why uptime metrics systematically overstate SLA compliance
Availability expressed as a percentage is a useful starting metric and an insufficient SLA measure. The number hides two things that matter enormously in practice: when the downtime occurred, and what the downtime prevented.
A system unavailable for 43 minutes distributed across overnight maintenance windows, on weekday nights at 02:00, has a different business impact than the same 43 minutes of unavailability occurring at 07:30 on the first business day after month-end when users are trying to access closing reports and the batch schedule is completing its final runs. Both produce identical availability percentages. The business consequences are not comparable.
Calendar-weighted availability, which applies higher weight to downtime during defined critical windows, is a more honest measure for SAP environments where the cost of unavailability is not uniform across the day or the month. A 15-minute outage during year-end close costs more operationally than a 4-hour outage on a Sunday morning. SLA definitions that do not acknowledge this asymmetry produce metrics that look fine on paper while failing the business they are supposed to protect.
The three layers where SAP SLAs actually live
Infrastructure availability: the floor, not the ceiling
Infrastructure availability, whether the SAP system can be reached, is the minimum condition for SLA compliance. A system that cannot be connected to has failed every SLA that requires it to be usable. But a system that can be connected to has not necessarily met any of them. Infrastructure availability is the necessary baseline, not the complete picture.
Measuring it correctly requires defining what “available” means in the contract. A system that responds to a network ping is available by one definition. A system that accepts dialog connections and returns transaction results within a defined response time is available by a stricter definition. Most SLA disputes about availability trace back to these two parties using different definitions of the same term.
Application performance: the middle layer most SLAs address incompletely
Dialog response time is the application-layer SLA metric that most directly maps to user experience. An SAP system that is infrastructure-available but serving dialog steps at 8 seconds on average is not meeting any reasonable performance commitment, even though the uptime measurement shows no degradation.
The measurement challenge is that response time varies by transaction, by time of day, by concurrent load, and by the specific data volumes involved. An SLA that says “average dialog response time below 2 seconds” is ambiguous: average across which transactions, during which hours, with which user count? Without those parameters defined, the SLA is not measurable without choosing the interpretation that produces the most favorable number.
The SLO (service level objective) that supports a response time SLA should define the measurement scope explicitly: the 95th percentile dialog response time across all standard transactions during business hours, measured at 5-minute intervals, should remain below 2 seconds. That definition has a single interpretation and can be measured consistently from monitoring data.
Business process completion: the layer almost no SLA currently measures
The commitments that the business actually depends on are process-level, not infrastructure-level. The financial close batch must complete by 06:00 on the second business day after month-end. Customer orders received before 16:00 must appear in the warehouse management system within 30 minutes. The nightly IDoc processing must achieve a success rate above 99.5% by 07:00.
These are measurable commitments. They require monitoring at the batch job completion layer, the interface success rate layer, and the business document creation layer, not at the server availability layer. Very few MSP SLAs and very few internal IT service agreements include them, because measuring them requires understanding the business processes well enough to define the completion criteria, and instrumenting the monitoring to capture whether those criteria were met.
The organizations that do define and measure process-level SLOs are the ones where the relationship between the IT team and the business is based on shared outcome data rather than infrastructure dashboards that neither side fully understands. Building that measurement layer is more work than tracking uptime. It is also considerably more honest about whether the service is actually being delivered.
The MTTR problem: measuring from impact, not from detection
Mean time to recover is a standard SLA metric for incident response. It measures the time between when a problem was detected and when it was resolved. In theory, a lower MTTR means faster incident response. In practice, it measures the wrong interval.
When a production system degrades at 02:15 and nobody detects it until 04:30, the measured MTTR starts at 04:30. If the incident is resolved by 05:00, the MTTR is 30 minutes. The actual service impact was 2 hours and 45 minutes. The MTTR of 30 minutes is technically accurate and operationally misleading.
SLA observability for incident response requires two separate measurements: time to detect (from impact to first detection) and time to resolve (from detection to resolution). Both are meaningful. MTTR alone systematically understates service impact in environments where detection gaps exist, which is most environments. An MSP that reports a 22-minute average MTTR without disclosing that the average detection delay is 90 minutes is presenting accurate data in a frame that obscures the full picture.
Time to detect is also the metric that most directly reflects monitoring quality. Reducing detection delay from 90 minutes to 5 minutes has more business impact than reducing resolution time from 30 minutes to 15 minutes. But time to detect only becomes a managed metric if it is being measured.
| Watch out: SLA definitions that only specify resolution time create an incentive to delay formal incident declaration. If the clock starts when the incident is logged rather than when the impact began, the measured MTTR depends on how quickly the team opens a ticket, not how quickly the service was degraded. This is not necessarily deliberate, but it systematically favors the provider over the client in any SLA review. Define impact start time in the SLA, not ticket creation time. |
What MSPs need to measure differently
An MSP managing SAP for multiple clients produces monitoring data from its own monitoring infrastructure and reports SLA compliance from that data. The client has their own perspective on whether the service was delivered. When these two perspectives produce different numbers, the dispute is as much about measurement methodology as about service quality.
The authoritative measurement question matters practically: in an SLA dispute, whose monitoring data governs? The contract should specify this, and it almost never does. In the absence of a contractual definition, both parties present their own data and the dispute resolution is slow and adversarial.
An MSP that adopts the client’s perspective on SLA measurement, using monitoring data that measures what the client experiences rather than what the infrastructure reports, eliminates this dispute by removing the gap between perspectives. That means measuring process completion times from the client’s business process layer, not just system availability from the infrastructure layer. It means defining time to detect from the moment of business impact, not from the moment the MSP’s monitoring alert fires. It means reporting on IDoc success rates and batch job completion windows alongside server uptime.
This approach requires more monitoring depth and more investment in understanding the client’s business processes well enough to define the right SLOs. It also produces SLA reporting that is genuinely informative rather than defensively constructed, which is a commercial differentiator in a market where clients are increasingly skeptical of availability percentages that do not explain why their processes still failed.
Error budgets as a practical tool for SLA management
An error budget is the amount of non-compliance that a given SLA permits over a defined period. If the monthly availability SLA is 99.9%, the error budget is approximately 43 minutes per month. That budget is spent every time the system is unavailable.
Tracking error budget consumption in real time changes the operational dynamic. When the monitoring shows that 35 of the month’s 43 available minutes have been consumed by Wednesday of the third week, the team has concrete data that drives a decision: planned maintenance scheduled for this weekend should be postponed, or rescheduled to a period with a fresh budget, because executing it now would consume the remaining budget and produce an SLA breach.
Error budgets also make the conversation about technical debt and reliability investment concrete. A system that consistently consumes 80% of its monthly error budget in unplanned incidents has a reliability problem that can be quantified. A system that reliably uses its error budget only for planned maintenance is demonstrably more reliable. The difference is visible in the error budget data over time, not just in incident counts.
For MSPs, error budgets create a shared framework with clients: both parties know how much of the month’s tolerance has been used, what remains, and whether any planned changes are safe to execute without risking a breach. That shared visibility replaces the end-of-month SLA review surprise with a running conversation grounded in real data.
The monitoring infrastructure that supports SLA observability is not fundamentally different from the infrastructure that supports operational monitoring. It collects the same data. What is different is the frame: instead of asking whether the system is currently healthy, SLA observability asks whether the commitments made for this month are still being honored, whether the budget for deviation is exhausted, and whether the process-level outcomes the business depends on are being delivered within the agreed windows.
That frame requires defining the SLOs precisely enough to be measurable, instrumenting the monitoring to capture the relevant metrics at the right layer, and reporting in a format that shows compliance against commitments rather than just infrastructure health. Most monitoring deployments do the third of those things. The first two are where SLA observability is actually built.
Redpeaks provides SLA dashboards for SAP managed services environments, covering availability windows, batch completion SLOs, interface success rates, and incident detection time, all in a format accessible to both operations teams and business stakeholders. See the SLA reporting features.
