SAP SM37 Background Job Monitoring: Find, Diagnose, and Recover Failed Jobs

01What SM37 monitors

SAP transaction SM37 is the central worklist for background jobs. Use it to find jobs by name, user, status, date, time, or execution server, then inspect the job log and spool output to determine what happened. SM36 is used to define and schedule jobs; SM37 is used to monitor their execution and results.

For broader operational context, see the SAP Basis system administration guide. It provides the surrounding checks that are useful when a job problem points to a system-wide issue.

02Selecting the right jobs

Start SM37 and enter the narrowest useful selection criteria. A productive first search usually combines the job name or a name pattern with the scheduling user and a realistic date range. Add the status when you already know whether the job is active, finished, cancelled, or scheduled.

Useful selection patterns include:

• Search a complete job name when investigating one known process.
• Use a controlled name pattern when a process creates a family of jobs.
• Filter by the job's scheduling user to separate application teams or interfaces.
• Include scheduled and released statuses when checking whether a job is waiting to run.
• Include active status when checking whether a long-running job is still executing.
• Extend the date and time range when a recurring job may have run across midnight.

Avoid starting with an unrestricted search over a long period in a busy system. A focused selection makes it easier to identify the correct job and reduces the chance of overlooking a similarly named run.

03Understanding job statuses

The status in SM37 describes the job's current lifecycle state. Scheduled jobs have scheduling information but are not yet released for execution. Released jobs are eligible to start when their conditions are met. Ready jobs have met their start conditions and are waiting for a background work process. Active jobs are currently executing. Finished jobs completed successfully from the background processing perspective. Cancelled jobs ended with an error or an explicit cancellation.

A job can remain in a waiting state because of a start time, event, predecessor, target server, or available background work process. Check the job's start condition and execution server before treating a waiting job as a failure.

04Reading the SM37 job log

Select the job and open its job log. Read the entries in chronological order, starting near the first warning or error and continuing through the final status message. The last message identifies where processing stopped, while earlier messages often contain the business object, selection value, or interface step that caused the failure.

Capture the job name, job count, user, start time, end time, status, and the relevant log messages before changing the schedule. These details make a later comparison with a successful run much more reliable.

A job log may show that the background framework started correctly while the application step failed. In that case, investigate the application message, variant, authorization, input data, or dependent interface rather than treating the scheduler itself as the root cause.

05Investigating cancelled jobs

When a job is cancelled, open the job log first and then review the job's step details. Confirm which program, variant, or external command was running when the cancellation occurred. Check whether the failure is repeatable with the same variant and input data.

Common investigation paths include:

1. Job log: identify the first meaningful error and the processing step where it occurred.
2. Spool request: inspect generated output for application messages, selection results, or termination details.
3. ABAP runtime errors: check ST22 when the log indicates a short dump or an ABAP termination.
4. System events: check the system log with SAP system log monitoring when the job failure coincides with a system, database, host, or communication event.
5. Work processes: check SAP work process monitoring when the job is active for an unusual duration or background capacity appears constrained.

A cancelled job should be rerun only after the cause and the business impact are understood. Repeating an interface, posting, or data-change job can create duplicates when the first run completed part of its work before termination.

06Checking job steps and spool output

Job step details show the executable object, variant, user, and execution information for each step. Compare these values with a successful run or the intended schedule. An incorrect variant or step user can produce a technically valid job that processes the wrong data or lacks the required authorization.

Open the spool output when the job generates a report or diagnostic list. Review the output for selection parameters, record counts, warnings, and application messages. Save the relevant spool information according to the operational retention policy before deleting old job data.

07Handling jobs that do not start

For a job that remains scheduled or released, open the start condition and verify the intended date, time, event, predecessor, and execution server. A job waiting for an event needs the producing process or event chain checked. A job assigned to a restricted server needs that server and its background work processes checked.

If the job is ready but does not start, inspect background work process availability and competing workloads. A temporary queue can clear without intervention; a persistent queue requires capacity and scheduling analysis.

08Managing recurring schedules safely

Use SM36 to review the recurring definition after diagnosing a run. Confirm the periodic interval, start conditions, job class, target server, step user, variant, and spool settings. Keep the monitoring selection in SM37 aligned with the actual job name and scheduling user so future failures are visible.

When a recurring job fails, preserve the failed run for analysis, correct the underlying condition, and coordinate the rerun with the process owner. Record whether the rerun is a full execution, a restart, or a compensating process.

09Operational checklist

Use this sequence for routine SM37 monitoring:

1. Search the expected job name and scheduling user for the relevant time window.
2. Confirm that the expected run exists and has the expected status.
3. Compare start and end times with the normal operating range.
4. Open the job log for warnings and errors.
5. Inspect step details and spool output.
6. Check ST22, the system log, or work process monitoring when the evidence points outside the job itself.
7. Assess duplicate-processing risk before rerunning a cancelled job.
8. Record the cause, action, result, and any schedule change.

This workflow separates a scheduler delay from an application failure and preserves the evidence needed for escalation or post-incident review.