SM50 — Work Process Overview for the Current Instance

SM50 reads the work process table held in the shared memory of the application server instance the user is logged onto and displays each work process: its type (dialog, background, update, update2, enqueue, spool), current status (running, waiting, PRIV, stopped), the user and client, the report or transaction executing, the table currently being accessed, and elapsed CPU and total time. The one fact that causes most confusion is scope: SM50 only ever shows the instance you are connected to. A production system with several application servers can look perfectly healthy in SM50 while a stuck process sits on a different instance entirely. Nothing displayed here is a database table in the conventional sense; it is a live read of dispatcher shared memory, which is why the screen refreshes and why closing it loses the snapshot unless a trace or log was written separately.

SM50 is reached for the moment someone reports the system is slow or hanging and a specific session or job needs to be identified in real time. Typical triggers: a user says their screen has been sitting on an hourglass for minutes, a background job is showing as active but producing no output, or a lock error is being investigated and someone needs to see which work process actually holds the resource. It sits upstream of more specialised tools: once a stuck process is identified in SM50, the investigation moves to SM12 for the lock table, SM13 for update requests, or ST22 for the resulting dump. For a cluster-wide picture rather than one server, SM66 is used instead. There is no Fiori app that replaces this granularity of live process inspection.

SM50 itself cannot be queried through SE16 because it is not a database table; proof has to come from the durable records left around the event. Note the exact timestamp and work process number from SM50, then open the system log filtered to that instance and time window to confirm a cancellation or timeout was actually logged. If the process was killed with a core dump, check the short dump list for a dump at the same timestamp, same user, same program. For lock-related hangs, capture the lock table entries before cancelling anything, since the entry disappears the moment the holding session ends.

SM50 is unchanged on S/4HANA; it remains a SAP GUI transaction with the same instance-local scope and the same process types. There is no Fiori app that replaces this level of live, per-process detail; monitoring at scale on S/4HANA has generally moved toward centralised tools outside SM50 itself, but for a hands-on check of what one instance is doing right now, SM50 is still the tool a Basis consultant opens first, exactly as in ECC.

This is Basis territory. A functional or ABAP consultant may spot the symptom (a save that never finishes, a transaction that hangs), but diagnosing and acting on SM50 belongs to Basis. A good handover includes the instance name, work process number, timestamp, the exact program or transaction shown, and whether the process was waiting on a lock, a database call, or private memory, so Basis does not have to re-discover the same snapshot after it has already scrolled past.

SM66 extends the same view across every application server and is the first stop when SM50 looks clean but users elsewhere still report a hang. SM51 shows the list of application servers themselves, useful for confirming instance names before cross-checking SM66. SM21 provides the durable log entry once a process shown in SM50 has been cancelled or has dumped. SM13 covers stuck update requests when a work process of type update is the one under investigation. SM04 lists active user sessions, useful for correlating a specific user's complaint with the session actually shown in SM50.