A blank Cloud ALM monitoring screen during an incident is more than an inconvenience; it raises a critical question: what is SAP Cloud ALM actually monitoring? When teams move away from Solution Manager, they can assume their existing monitoring coverage will follow them. In practice, SAP Cloud ALM has specific monitoring boundaries, and understanding those boundaries matters when an IDoc fails, an integration breaks, or an application starts behaving unexpectedly.
The challenge is knowing which systems, processes, and technical layers Cloud ALM can observe, which ones require additional configuration, and where custom monitoring data fits in. Without that clarity, teams can waste valuable incident-response time looking for information the platform does not provide by default. This guide breaks down five practical SAP Cloud ALM monitoring use cases, including its coverage, limitations, and options for feeding custom data into the platform.
What Is SAP Cloud ALM Monitoring, and Why Does It Matter
SAP Cloud ALM monitoring is the operations layer of SAP Cloud ALM, the SaaS-delivered application lifecycle platform SAP positions for observing hybrid landscapes. SAP provides it at no extra license cost to customers with Enterprise Support for cloud editions or Product Support for large enterprises. This pricing model has helped drive adoption among teams that still use Solution Manager for change and transport activities.
SAP Cloud ALM Monitoring Covers Five Use Cases
Moreover, SAP Cloud ALM monitoring is not one screen. It consists of five distinct use cases under SAP Cloud ALM for Operations. These include Health Monitoring, Integration & Exception Monitoring, Job & Automation Monitoring, Real User Monitoring with its synthetic counterpart, and Business Process Monitoring.
These capabilities are then brought together through Business Service Management, which provides a consolidated status view for defined services. Each use case, however, has its own scope selector, supported solutions, and data collection mechanism. As a result, connecting a system in landscape management does not automatically mean that every monitoring application can collect data from it.
Why Monitoring Scope Matters
This distinction becomes important for teams moving from Solution Manager because they may expect SAP Cloud ALM monitoring to behave like a single monitoring layer that automatically observes everything once a system is connected. In practice, coverage depends on the specific monitoring use case and the configuration behind it.
SAP Integration Suite is a useful example. Administrators can register an Integration Suite component centrally and see it in the system, while Integration & Exception Monitoring still provides only partial coverage. Understanding that boundary before an incident is far more useful than discovering it during a production bridge call.
The same principle applies when troubleshooting an apparently empty monitoring view. Before assuming that Cloud ALM has failed to collect data, check whether the relevant solution is supported, whether the correct scope has been selected, and whether the required data collection mechanism has been configured for that particular use case.
SAP Cloud ALM Monitoring Resources and Housekeeping
There is also a resource-management aspect that teams can overlook when planning SAP Cloud ALM monitoring. Cloud ALM runs on a shared tenant with default resource allocations that are generally sufficient for standard monitoring scenarios. However, memory consumption and outbound API usage are visible in the Tenant Information app.
Reviewing these values periodically can help identify resource pressure before it affects monitoring operations or historical data requirements. Housekeeping settings can also reduce memory consumption without immediately requiring a tenant extension.
If the default resources are genuinely insufficient for the monitoring volume, SAP provides a paid tenant extension option. Therefore, teams should treat resource monitoring as part of ongoing Cloud ALM administration rather than something to investigate only after a capacity-related issue appears.
The important point is that SAP Cloud ALM monitoring should be planned around use-case coverage, scope, data collection, and resource requirements. Connecting a system is only the starting point; validating what Cloud ALM can actually monitor from that system is what determines whether the monitoring setup will be useful during an incident.
How SAP Cloud ALM Monitoring Works
Under the hood, SAP Cloud ALM monitoring uses different data collection patterns depending on the system, service, or monitoring use case. Understanding these patterns helps you identify why a particular signal appears in Cloud ALM—or why it does not.
Pull and Push Data Collection
The first pattern is pull. For SAP-managed cloud services and supported on-premises ABAP systems, SAP Cloud ALM pulls monitoring data through communication scenarios. SAP_COM_0527 is one of the key communication scenarios teams configure because it supports health monitoring, Job & automation monitoring, and parts of Real User Monitoring for ABAP-based components.
Landscape management is where this connectivity is configured and maintained. It is also where you can check which monitoring use cases a particular system type supports before starting the configuration. Skipping this validation can lead to a monitoring gap that looks like a technical failure but simply reflects unsupported functionality or missing configuration.
The second pattern is push, which applies to components outside SAP’s own instrumentation. For example, a custom BTP microservice, an open-source component, or a non-SAP application may need to send monitoring data into SAP Cloud ALM. The Raw Data API handles this scenario using the OpenTelemetry protocol rather than a proprietary SAP format.
You can send metrics, logs, or traces as OpenTelemetry payloads using protobuf or JSON to a dedicated HTTP endpoint. Cloud ALM then processes the incoming data for health monitoring. For inbound metrics, the current API supports gauge, sum, and histogram metric types. Therefore, teams should design their metric model around these supported types rather than creating unsupported custom metric structures.
Business Process Monitoring Uses a Different Model
Business process monitoring works differently from both pull and push collection. Instead of collecting general technical telemetry, it uses predefined KPIs delivered by SAP. For ABAP-based systems, these KPIs depend on the ST-A/PI add-on being current.
SAP’s Business Process Monitoring setup documentation requires a version later than 01U_731 for S/4HANA and Business Suite 7. Because the requirement is stated as “greater than,” version 01U_731 itself may not qualify. Always verify the installed version against the current SAP documentation before go-live.
If the ST-A/PI add-on falls behind, new KPI content may not appear even though the monitoring configuration itself looks correct. This can make the issue difficult to identify because there may be no obvious error pointing to the outdated add-on.
Customer-defined KPIs also need careful consideration. ABAP-based custom KPIs and the BTP-based custom KPI framework do not necessarily follow the same delivery timeline or implementation model. The BTP framework already supports custom KPIs based on OpenTelemetry instrumentation, while ABAP-based capabilities are evolving separately. Therefore, do not assume feature parity simply because both capabilities appear within SAP Cloud ALM.
Job and User Monitoring
Job & Automation Monitoring focuses on what was scheduled and what was actually executed. It can identify failed jobs, runtime issues, and certain scheduling or authorization-related conditions. For example, it can alert when a job is scheduled by a user who should not be scheduling it or when an allowed job fails or exceeds its defined runtime limit.
There is also an important BW-related detail to remember. Jobs that execute RSPROCESS as part of a BW process chain may not appear in Job & Automation Monitoring in exactly the same way they appear in SM37. Cloud ALM treats those jobs as elements of the process chain rather than simply displaying them as standalone jobs. As a result, a difference between SM37 and Cloud ALM does not automatically mean that monitoring is broken.
User monitoring covers two different scenarios: real user monitoring and synthetic user monitoring.
Real User Monitoring captures activity from actual business users, including timings such as page-load and response times and relevant error information. For Fiori scenarios, this relies on client-side instrumentation associated with the Fiori launchpad.
Synthetic User Monitoring takes a different approach. It executes predefined scripts at scheduled intervals, allowing teams to test critical user journeys even when nobody is actively using the system. This makes it particularly useful for detecting failures during off-hours.
Neither approach completely replaces the other. Real User Monitoring provides visibility into genuine user activity, while Synthetic User Monitoring can proactively test known business flows. Relying only on real-user data can leave off-hours gaps, while relying only on synthetic scripts limits monitoring to the scenarios those scripts actually cover.
Business Service Management Consolidates the Signals
Business Service Management sits above the individual monitoring capabilities. It does not independently collect monitoring data. Instead, it consolidates signals from other SAP Cloud ALM applications into a business-oriented status for a defined service.
This view can be valuable during an operations bridge because it gives teams a higher-level picture of service health. However, a green status does not necessarily prove that the underlying landscape has complete monitoring coverage.
For example, a service may appear healthy simply because none of its components is configured for the monitoring use case that would have detected a particular problem. That is why teams should investigate the individual monitoring use cases when troubleshooting rather than relying exclusively on the Business Service Management roll-up.
Understanding these collection patterns and monitoring layers makes SAP Cloud ALM easier to troubleshoot. Instead of asking why a metric or alert is missing from the overall landscape, you can first identify the relevant use case, determine how it collects data, and then verify the corresponding system scope and configuration.
Quick Reference: What Covers What
- Health Monitoring—system/application up-stage. Pull via SAP_COM_0527, or push via the Raw Data API for custom components.
- Integration & Exception Monitoring—message/interface failures. Alerts on ERROR status only, not on stuck-but-non-error states like “Delivering.”
- Job & Automation Monitoring—scheduled vs. actual job execution. BW process-chain jobs won’t appear the way they do in SM37.
- Real User / Synthetic Monitoring—actual user experience vs. scripted 24/7 checks. Use both; neither alone covers off-hours coverage and full-path coverage.
- Business Process Monitoring—end-to-end KPI health. Requires ST-A/PI later than 01U_731 for ABAP-based systems.
- Business Service Management—rolls up the above into one status. A green light here doesn’t mean full coverage underneath — it means everything configured is healthy.
Practical Code Walkthrough: Pushing a Custom Metric
Say you want SAP Cloud ALM monitoring, specifically the Health Monitoring use case, to track a custom queue depth from an on-premises ABAP system that does not have native instrumentation. This is a common requirement once teams realize that standard monitoring content does not cover every custom interface they have built over the years.
The Raw Data Inbound Metrics API is the mechanism for this, and the pattern is straightforward once you understand the OpenTelemetry shape it expects: build a JSON body describing a resource and its metrics, then POST it with an OAuth token issued against your Cloud ALM service key.
Here’s a minimal ABAP report doing exactly that.
REPORT z_calm_push_custom_metric.
" S/4HANA 1909+ or BTP ABAP Environment required for CL_HTTP_CLIENT with SSL client cert / OAuth
DATA: lo_http_client TYPE REF TO if_http_client,
lv_body TYPE string,
lv_token TYPE string,
lv_metric_val TYPE p DECIMALS 2,
lv_epoch_nanos TYPE string.
" Step 1: read the value you want to report - here, a custom queue depth check
SELECT COUNT(*) FROM z_outbound_queue
WHERE status = 'PENDING'
INTO @lv_metric_val. " simple gauge value
" Step 2: get an OAuth token for the Cloud ALM tenant
" (token retrieval abstracted - use CL_OAUTH2_CLIENT with the client credentials
" from your Cloud ALM service key, stored in a secure storage, not hardcoded)
lv_token = get_calm_oauth_token( ).
" Step 3: build a Unix-epoch-nanosecond string for OTLP's "timeUnixNano" field.
" NEEDS SME VERIFICATION / TESTING IN YOUR SYSTEM: the exact conversion from an
" ABAP UTC timestamp to a nanosecond-epoch string depends on your release and
" available timestamp utilities (e.g. UTCLONG, CL_ABAP_TSTMP). Validate the
" resulting value against a known-good OTLP example before relying on it -
" a malformed timeUnixNano can cause the datapoint to be silently dropped
" rather than throwing a visible error.
lv_epoch_nanos = get_unix_epoch_nanos( ). " placeholder for your validated conversion logic
" Step 4: build the OpenTelemetry Metrics JSON payload
" resourceMetrics.resource.attributes "service.name" is mandatory - free text value
lv_body = |\{| &&
|"resourceMetrics": [\{| &&
|"resource": \{"attributes": [\{"key": "service.name",| &&
|"value": \{"stringValue": "Z_OUTBOUND_QUEUE"\}\}]\},| &&
|"scopeMetrics": [\{"metrics": [\{| &&
|"name": "outbound_queue_pending_count",| &&
|"gauge": \{"dataPoints": [\{| &&
|"asDouble": { lv_metric_val },| && " the value itself
|"timeUnixNano": "{ lv_epoch_nanos }"| &&
|\}]\}| &&
|\}]\}]| &&
|\}]| &&
|\}|.
" Step 5: create the HTTP client and POST to the Raw Data Inbound Metrics endpoint
cl_http_client=>create_by_url(
EXPORTING
url = 'https://<your-tenant>.cloudalm.cloud.sap/api/raw-data/v1/metrics'
IMPORTING
client = lo_http_client ).
lo_http_client->request->set_header_field( name = 'Authorization'
value = |Bearer { lv_token }| ).
lo_http_client->request->set_header_field( name = 'Content-Type'
value = 'application/json' ).
lo_http_client->request->set_cdata( lv_body ).
lo_http_client->request->set_method( if_http_request=>co_request_method_post ).
lo_http_client->send( ).
lo_http_client->receive( ).
" A 200 here means the message reached the queue - it does NOT confirm it
" was processed. Set up API self-monitoring in Cloud ALM to catch silent drops.
IF lo_http_client->response->get_status( ) = 200.
WRITE: / 'Metric pushed - check Health Monitoring in 5-10 minutes'.
ENDIF.When to Use It vs. Alternatives
SAP Cloud ALM monitoring is not a universal replacement for every tool it superficially resembles, and treating SAP Cloud ALM monitoring as one is where a lot of implementation timelines go sideways. It’s strongest for cloud-native and hybrid landscapes where standardized, low-configuration coverage matters more than deep, system-by-system customization — which is by design, since SAP built it as a content-driven platform rather than a customizing-heavy one.
| Capability | SAP Cloud ALM Monitoring | SAP Solution Manager | SAP Focused Run |
| Licensing cost | Included with Enterprise Support (cloud editions) | Included, but on-prem infrastructure required | Separately licensed |
| Best fit | Cloud-centric / hybrid, standardized ops | Big change, transport, and CHARM processes | High-volume, high-frequency technical monitoring |
| Customization depth | Limited content-driven, SAP-defined | Extensive, ABAP-based customizing | Extensive, built for large landscapes |
| Non-SAP / custom app monitoring | Yes — via OpenTelemetry Raw Data API | Limited | Yes, with agents |
| Database-level monitoring | Not directly—app/UI layer only | Yes | Yes |
| Deployment | SaaS, no infrastructure to run | Requires on-premises system | Requires dedicated infrastructure |
Conclusion
SAP Cloud ALM monitoring isn’t one dashboard it’s five separate use cases with five separate scopes, and assuming otherwise is what turns a routine incident into a landscape-wide guessing game. Each use case has its own data sources, configuration requirements, and monitoring scope, so knowing where the data comes from matters just as much as knowing where to find it.
Once you understand which layer of SAP Cloud ALM monitoring collects data automatically, which requires a communication scenario or integration setup, and which depends on custom OpenTelemetry data, the monitoring landscape becomes much easier to manage. You can also narrow down issues faster by checking the selected systems, services, scope, and data source before investigating deeper technical causes.
This distinction becomes especially important in hybrid SAP landscapes, where S/4HANA, SAP BTP, cloud services, and external platforms may all contribute monitoring data. A missing metric, empty monitoring screen, or incomplete view does not always indicate a system failure. In many cases, the problem starts with scope selection, configuration, integration, or the way monitoring data reaches SAP Cloud ALM.
Therefore, treat SAP Cloud ALM monitoring as a set of purpose-built monitoring capabilities rather than a single centralized dashboard. Check your scope selectors and data sources before your next go-live, validate the required integrations in advance, and make sure your team knows which monitoring use case applies to each operational scenario. That preparation can turn troubleshooting from a broad search across the landscape into a focused investigation of the right system and the right monitoring layer.
Frequently Asked Questions
Is SAP Cloud ALM free to use?
Yes there’s no separate license fee. Customers with Enterprise Support for cloud editions, or SAP Enterprise Support / Product Support for Large Enterprises, get one SAP Cloud ALM monitoring tenant included, with sap cloud alm monitoring apps activated automatically after subscription.
What’s the difference between SAP Cloud ALM and Solution Manager?
SAP Cloud ALM is SAP’s cloud-native ALM platform; it is not built as a one-to-one replacement for Solution Manager. It takes a standardized, content-driven approach, while Solution Manager retains deeper ABAP-based customizing for change, release, and transport-heavy processes.
Can SAP Cloud ALM monitor on-premise systems?
Yes. SAP Cloud ALM monitoring supports hybrid landscapes, including select on-premise ABAP systems connected through communication scenarios like SAP_COM_0527, though feature parity with cloud-native systems varies by monitoring use case.
Why is SAP Integration Suite visible in Landscape Management but missing from the Health Monitoring scope?
Each SAP Cloud ALM monitoring use case defines its own supported-solutions scope independently. A service can be registered centrally in Landscape Management while still being unsupported or only partially supported—by a specific monitoring app like Health Monitoring.
Can SAP Cloud ALM monitor the SAP Cloud Connector directly?
Not currently. Community discussion confirms there’s no dedicated content for Cloud Connector monitoring in Health Monitoring or Integration & Exception Monitoring today; it remains an open roadmap item rather than a supported use case.
How do I monitor a PostgreSQL database through SAP Cloud ALM?
SAP Cloud ALM monitoring doesn’t observe databases directly. If the database sits behind an app or UI layer, you monitor that layer instead, using health monitoring or integration & exception monitoring as applicable.
Why do SAP Cloud ALM alert emails stop sending without any configuration change?
This has occurred as an intermittent global service issue rather than a customer-side misconfiguration, according to SAP Community reports, and was resolved on SAP’s side. If alert emails stop unexpectedly, check the SAP Cloud ALM status page before troubleshooting your own settings.
Does Job & Automation Monitoring cover jobs scheduled directly in the database, bypassing SM36?
No it monitors jobs scheduled and tracked through standard SAP job scheduling mechanisms; jobs injected outside that path won’t be visible or governed by the “who’s allowed to schedule” alerting.
Can I use SAP Cloud ALM monitoring alongside Focused Run instead of choosing one?
Yes SAP explicitly supports running them together, with Cloud ALM covering standardized cross-landscape visibility and Focused Run covering high-volume, high-frequency technical monitoring for large on-premises estates.
