ST06 — ST06 Operating System Monitor

ST06 displays operating system resource consumption for the host of the current instance: CPU load and utilization, memory usage and paging rate, disk throughput, and network statistics. The figures are not read directly from the kernel by the ABAP report; they are collected continuously by a separate OS process called saposcol and handed to ST06 through shared memory. This is the structural fact that explains most confusion: ST06 can look calm while the server is struggling, or look alarming while the server is fine, whenever saposcol itself is stuck, restarted, or lagging. The transaction is host-scoped, not system-scoped, so a system with several application servers requires switching hosts to see the full picture.

Consultants reach for ST06 early in performance triage, before diving into ABAP traces or SQL, whenever the complaint is generic slowness with no obvious dialog or database signature. It sits alongside SM50 and SM66 for work process load, ST02 for buffer and extended memory pressure, and ST04 for database-side waits. If CPU, memory, and disk on ST06 all look unremarkable, the investigation moves into the ABAP or database layer instead of chasing hardware. It is not used for capacity planning trend reports, which belong to longer-term monitoring tools; ST06 is a short-window, near-real-time view.

There is no SE16 table to query for ST06 because it does not write application data; the recipe instead is cross-validation. Compare the CPU and memory figures shown in ST06 against a direct OS-level check on the same host at the same minute, using whatever native tool the OS admin has (process and memory listing commands). A large discrepancy, or a timestamp on the collector status screen that is minutes or hours old, confirms a stale-collector problem rather than a genuine resource shortage.

ST06 and ST06N are unchanged on S/4HANA for application server host monitoring; saposcol still does the collecting. The database host runs on HANA, and its OS-level figures are better checked through DBACOCKPIT or HANA-specific tooling rather than ST06, since ST06 on an app server does not see the HANA box. In RISE or other managed S/4HANA setups the underlying OS is often not directly accessible, and OS-level monitoring shifts to the hyperscaler or SAP-managed monitoring layer, with ST06 still available inside the system but less useful without corresponding OS access.

This is a Basis and OS administration problem, not a functional one. Functional teams report the symptom, slow response for a transaction or job, but the diagnosis and fix belong to Basis, who correlate ST06 with the actual OS tools and restart saposcol if needed. A good handover states the host, the exact time window of the complaint, and whether the collector timestamp on ST06 looked current at that time.

ST02 gives the ABAP buffer and extended memory side that ST06 memory figures are often confused with. ST04 covers the database layer, useful once hardware is ruled out. ST03 shows workload statistics per transaction over time, useful for correlating a slow period with the exact ST06 window. SM50 and SM66 show what the work processes were actually doing during that window, which turns an OS-level anomaly into an application-level explanation or rules it out.