RZ20 — CCMS Alert Monitor for cross-instance health checks

RZ20 is the CCMS Alert Monitor. It presents a tree of monitoring tree elements (MTEs), each representing a system resource such as a dialog work process queue, a buffer, spool, or the database, grouped by system and instance, and colored green, yellow, or red against configured thresholds. The one structural fact that explains most confusion is that RZ20 is not a live query tool for everything it shows. Data is gathered by monitoring segments per instance and by collector agents running at intervals; some values refresh on tree expansion, others are periodic snapshots. A node can be green because it has not been recollected recently, and a node showing no data at all almost always means the collecting agent or its connection is down, not that the underlying resource is fine.

RZ20 is reached during performance troubleshooting when the goal is to see which instance or resource is under stress before drilling into single-instance transactions. It is the natural first stop after an alert notification (email or SMS triggered by a CCMS auto-reaction) or before opening a system-wide status check across a landscape of app servers. Consultants use it instead of SM50 or SM66 when the question is which server has the problem, not what a specific server is doing right now. In S/4HANA landscapes with Solution Manager or Focused Run, aggregated multi-system monitoring is often done there instead, but RZ20 remains the local, no-dependency fallback on the individual system, and it is still where CCMS-native thresholds and auto-reactions are configured and observed.

RZ20 mostly shows shared-memory data rather than a table anyone can query directly, so proving a symptom means cross-checking the underlying source rather than reading an RZ20-specific table. For a trend-based alert (CPU, response time, buffer hit ratio), pull table MONI, filter by the instance or server name field and the relevant time interval, and compare recorded values against the threshold shown in the RZ20 alert detail to confirm the spike actually happened rather than being a leftover alert. For a connectivity-related gray node, the proof is a failed connection test on the RFC destination behind the monitoring segment, checkable from SM59.

RZ20 is unchanged in structure on S/4HANA; CCMS monitoring continues to run and the transaction is not deprecated. What has shifted is emphasis: database and workload monitoring for HANA increasingly lives in HANA-native tooling and in Fiori-based system monitoring apps, and multi-system aggregation is more commonly done through Solution Manager or Focused Run rather than through RZ20's own cross-system monitor sets. RZ20 remains the direct, dependency-free view on a single system and is still the place CCMS thresholds and auto-reactions are actually observed.

Basis owns RZ20 and any threshold or monitor set configuration. A functional consultant who spots a red alert should hand it over with the exact node path, the timestamp, whether the alert was completed or is still open, and any drill-down result already obtained from SM50 or ST04, rather than requesting a threshold change directly.

SM50 and SM66 are the natural next stop from a red work-process node, showing live process detail on the affected instance or across the whole system. ST04 is the destination for database-related alerts, and DB02 for space and object-level detail. SM21 is worth checking alongside a red system-log node since CCMS alerts and syslog entries frequently describe the same underlying event from two angles. Reading RZ10 and RZ11 afterward helps when an alert turns out to trace back to a profile parameter rather than a transient load spike.