Atlas Diagnostic

SAP application log diagnostics

A first-pass structure for finding incident evidence in SAP application logs, system logs, and developer traces.

Reviewed

Core idea

Application logs are often the fastest way to narrow an incident to a component, user, or transaction. When the symptom is vague, the goal is to move from the business report to the concrete log object, time window, and error text.

Common symptoms

  • A process failed but no application error message is visible to the user.
  • The support team needs to prove whether an error originated in SAP or in a connected system.
  • An interface or batch job failed and the job log is too short to explain why.
  • A user reports intermittent failures that are hard to reproduce.
  • A custom program or enhancement behaves unexpectedly after a transport.

Likely causes

  • Log object not activated: the application writes to a log object that is not active in SLG0/SLG2.
  • Wrong log level: the log is configured for errors only and omits the warning that explains the root cause.
  • Time-window mismatch: the log is searched outside the actual failure window.
  • Object overwritten: old log entries were deleted by housekeeping before the incident was reported.
  • Trace not collected: a short dump or SQL trace was not captured at the moment of failure.

Where to check in SAP

  • SLG1 — application log: filter by log object, sub-object, external ID, or time.
  • SM21 — system log: check for operating-system level or kernel errors around the failure time.
  • ST22 — short dump analysis for ABAP runtime errors.
  • ST05 / SQL trace — capture database activity if the issue is reproducible.
  • SM50 / SM66 — work process overview for stuck or failed dialogs.

Key tables / transactions / objects

  • SLG1 / SLG2 — application log entries and display.
  • SNAP — short dump header data.
  • TBPROF / TSP02 — spool and print request tables.

Diagnostic workflow

  1. Confirm the exact time, user, transaction, and business object involved in the incident.
  2. Open SLG1 and filter by the relevant log object/sub-object or external ID.
  3. If SLG1 is empty, check SM21 for system-level errors in the same time window.
  4. For ABAP dumps, open ST22 and search by date/user/transaction.
  5. If the failure is reproducible, run ST05 or SAT to capture SQL or runtime trace.
  6. Document the log object, message ID, and timestamp; correlate with business process step.

Typical fixes or next actions

  • Activate or extend the relevant log object in SLG0 if logging is missing.
  • Adjust log retention or archive strategy so recent incidents are still available.
  • Add explicit error handling and logging in custom code.
  • Route critical log objects to alerting or incident workflow.
  • Escalate to development or basis if the trace points to a program or kernel issue.

Support takeaway

A useful log investigation ticket includes: time window, user/background user, transaction or program name, business object ID, and the exact symptom. Without this context, log searches become slow and inconclusive.

Boundaries and non-goals

This page is a diagnostic frame, not a configuration guide for SAP Log Management or SAP Cloud ALM. It does not cover detailed trace interpretation or code debugging.

This is not official SAP documentation and not a replacement for system-specific analysis.