SM04 — User Sessions Monitor for the Local Instance
SM04 is a live monitor of user sessions on the ABAP application server instance you are currently logged onto. It shows who is logged on, how many sessions each user has open, and which transaction each session is running, and lets an authorized user terminate a session. It reads shared memory, not a database table, and by default covers only the local server, not the whole system.
SM04 lists the users and sessions active on a single application server instance and lets an administrator inspect or terminate them. This page covers the scope trap that causes most confusion, the real diagnostic order for a stuck or reappearing session, and how to corroborate what happened afterward since the transaction itself leaves no data footprint.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,058 words
Purpose
SM04 displays the list of users and open GUI sessions on the application server instance the administrator is currently connected to: user name, client, number of sessions, terminal or IP, and the transaction code each session is currently executing. From here a session can be inspected in detail or ended. The structural fact that causes most confusion is scope: SM04 is local to the instance the caller is logged onto. In a system with multiple application servers, a runaway session may be running on a different server and will simply not appear. The transaction has a menu option to switch to another server's session list, but it does not aggregate automatically the way AL08 does across the whole system.
When it is used
Reached for before planned downtime, to confirm no one is still logged on before restarting the instance or client. Used when a user reports being logged out unexpectedly, or when licensing or session-count limits are being investigated for a specific user id. Used to kill a session that is stuck in an endless loop, holding a lock, or blocking a transport or client copy. For a system-wide view across all application servers, AL08 is used instead. For checking whether a specific work process is hung rather than just idle, SM50 or SM66 is the better starting point, since SM04 shows the session but not the work process state behind it.
How to use it in practice
- Run SM04; the list defaults to the local application server instance
- Review the session count and current transaction column per user to spot idle, stuck, or duplicate sessions
- Double-click a user line to expand the individual sessions and see the program or transaction each one is in
- Select a session and use the menu option to end it, confirming the warning prompt since this is a hard kill, not a graceful logoff
- Use Goto and the server selection option to repeat the check on another application server if the system has more than one instance
- Cross-check SM12 immediately after if the session was killed to confirm whether it was holding locks that now need manual review
Key data objects
- No persistent table - the session list is assembled live from the instance's shared memory and work process table, so nothing is written when SM04 is opened
- USR41 - holds last logon date and time per user, useful as after-the-fact corroboration since it survives after the session itself is gone
- SM21 system log entries - a forced session termination generates a log record with user, time, and terminating administrator, which is the closest thing to an audit trail this transaction produces
How to prove it in the data
Because SM04 has no backing table, proof after the fact comes from SM21: filter the system log by the affected user id and the approximate timestamp, looking for the logoff or session-termination message and the id of the administrator who triggered it. To confirm a user's last actual logon independent of SM04, check USR41 filtered on the user id and compare the timestamp against the incident window. If the concern is locks left behind by a killed session, check SM12 filtered on the same user id right after termination.
ECC vs S/4HANA
SM04 is unchanged on S/4HANA and remains available in the SAP GUI exactly as on ECC. There is no dedicated Fiori app that replaces this specific local-instance session view; administrators on S/4HANA still use SM04 for single-instance checks and AL08 for the system-wide equivalent. No behavioral or authorization model changes are documented for this transaction across releases.
Common pitfalls and how to diagnose them
- Wrong scope - the administrator checks SM04, sees no trace of the reported user, and concludes the user is not logged on, when the session is simply running on a different application server. Switch server via the menu or use AL08 before ruling anything out.
- Kill does not release locks - ending a session in SM04 terminates the dialog process but does not always immediately clear entries in SM12 if the session was mid-update; check SM12 afterward rather than assuming the lock is gone.
- Session reappears instantly - the user is killed but shows up again seconds later; this usually means an automated logon (RFC connection, batch job, or scheduled report) is reconnecting, not that the kill failed. Check SM51 or the relevant job or RFC destination rather than repeating the kill.
- Silent authorization failure - a user without the administration authorization object for ending sessions sees the option greyed out or gets no effect; this is often mistaken for a technical bug rather than a missing authorization.
- Session count versus user count confusion - one physical user id can open several sessions in the same logon, inflating the apparent user count; relevant when investigating license or logon-limit disputes, since the count in SM04 is sessions, not distinct users.
Whose problem this is
This is Basis territory. A functional consultant may be the one reporting a stuck user or a session that will not release a lock, but the diagnosis and any session termination belongs to Basis. A good handover includes the user id, the exact timestamp the issue was observed, the transaction the user reported being in, and whether the session has already been killed once and reappeared.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/sm04ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.