SM21 — System Log Display

SM21 is the display transaction for the SAP system log, a kernel-generated record of events that sit below the ABAP application layer: work process restarts and terminations, database logon and connection failures, RFC and gateway errors, security audit events, and short dump triggers. It is a viewer, not a maintenance transaction; there is nothing to configure or save from the screen itself. The one structural fact that causes most confusion is that the log is not a permanent database table. Each application server instance keeps its own log as a rolling file at the operating system level, sized and rotated by profile parameters, so entries from several days ago may simply no longer exist by the time someone goes looking for them.

SM21 is reached for whenever something failed at a level below what the ABAP stack trace can explain: a work process died mid-transaction, a batch job hung with no dump, a user got kicked out with a generic connection error, or an RFC destination started failing intermittently. It is also the first stop for correlating timing across multiple dialog or background work processes during an outage, and for checking whether a security-relevant event (failed logons, authorization check overrides, password resets) was logged at the kernel level. Functional consultants rarely open it directly; it is Basis's first diagnostic step, usually opened within minutes of a P1 ticket, before ST22 dump analysis or SM50 process inspection.

There is no table to query directly for raw system log content, so SM21 is itself the proof tool: filter on the exact date and time window of the incident, the specific application server, and if needed the message class or user shown in the ticket, then export the filtered list rather than relying on memory of what was seen. To corroborate volume or recurrence, run the same filter across a wider window and count repeated identical messages, which often exposes a background job or interface looping rather than a one-off fault.

SM21 works the same way on S/4HANA as on ECC; the transaction, its filtering logic, and the underlying rolling log-file architecture are unchanged. Central log collection and retention are still governed by the same kernel-level profile settings rather than anything HANA-specific. There is no dedicated Fiori app that replaces it for ad hoc diagnostic use; Basis teams continue to open SM21 directly during incidents on both ECC and S/4HANA.

System log analysis is Basis territory from start to finish; functional and ABAP teams are consulted only to interpret what a specific message means for their process. A clean handover includes the exported filtered list, the exact server and time window checked, and a note on whether central logging was in scope, so the receiving team is not re-running the same filter from scratch.

SM50 and SM51 give the live and per-server work process view that SM21 entries often reference by process number, useful for confirming whether a logged termination corresponds to a process still visible or already gone. RZ20 surfaces the same class of kernel and performance alerts through the CCMS monitoring architecture, useful when the same failure needs to be tracked proactively rather than after the fact. SLG1 is the application log counterpart, holding custom ABAP messages that SM21 deliberately does not show, and is the next stop when the kernel log is clean but the functional process still failed.