ST03 — Workload Monitor for Response Time Analysis
ST03 (usually run as ST03N) is the workload monitor. It breaks down system response time by task type, transaction, program and user over a chosen time window, splitting total response time into wait, roll, load, database and CPU components. It is the standard first stop for 'the system is slow' complaints, but its historical data depends entirely on a background collector job that can silently fail.
This page covers what ST03 actually measures and the structural gap between live buffer data and collected historical data that causes most misreadings. It walks through the practical navigation sequence, what gets written where, and a ranked list of diagnostic pitfalls consultants hit when using it under pressure.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,064 words
Purpose
ST03 (in current systems the enhanced variant ST03N) is the workload monitor. It aggregates the statistical records every dialog step, RFC call and background job generates and presents them as response time per hour, per day, per transaction, per user or per task type. The one fact that explains most confusion: data for 'today' is read live from the current buffer, while anything older comes from a nightly collector job (RSCOLL00 and related variants) that writes aggregated snapshots. If that job did not run, or failed partway, the historical view for that day looks empty or artificially low, and it is easy to mistake a missing collector run for a genuinely idle system.
When it is used
ST03 is reached for whenever someone reports the system was slow at a specific time, before and after a transport or upgrade to compare baseline response times, or during capacity planning to see growth in dialog steps and CPU time over weeks. It is also used to identify which transaction or program is driving load during a peak period, before drilling into SM50 or ST04 for the live process or database view. It is not the tool for right-now process snapshots — that is SM50 or SM66 — and it is not the tool for buffer or memory sizing, which is ST02. ST03 answers 'what happened over this period', not 'what is happening right now'.
How to use it in practice
- Execute ST03N (ST03 routes to it on current releases)
- Pick the analysis view: workload overview, transaction profile, or time profile
- Select the period — today, yesterday, a specific week, or a custom date range
- For a multi-server landscape, switch between the current instance view and the total/aggregated view across all application servers
- Drill into a specific hour or transaction to see the response time breakdown: wait time, roll time, load/generation time, database time, CPU time
- Compare the selected period against an earlier baseline period for the same transaction or user group
Key data objects
- TCOLL - registers the performance data collector programs (such as RSCOLL00 and its hourly/daily variants), their scheduled frequency and the timestamp of the last successful run; the first place to check when historical data is missing
- Statistical record buffer - each work process writes per-step records here as work happens; ST03N reads this directly for the current day, not through a conventional client-visible table
- Aggregated workload history - a set of cluster structures built by the collector jobs from the raw statistical records, holding the hourly, daily and weekly summaries shown for past periods; not meaningfully browsable in SE16, only through ST03N itself
How to prove it in the data
To confirm a missing-data symptom rather than guess, open TCOLL via SE16 and check the last-run timestamp and status for the collector variant covering the day in question. If it is stale or shows an error status, cross-check the corresponding job in SM37 for that date and look for a cancellation or a long runtime that pushed it past its window. If TCOLL shows the collector ran fine, the gap is real system behaviour, not a monitoring gap, and the investigation should move to SM21 or ST04 for that time window instead.
ECC vs S/4HANA
ST03N works the same way on S/4HANA and remains the standard workload monitor; there is no functional replacement forcing migration away from it. For database-layer detail on HANA, ST04 gives HANA-specific views that complement rather than replace ST03N's application-layer breakdown. No Fiori app has generally superseded ST03N for this kind of historical workload drill-down.
Common pitfalls and how to diagnose them
- Missing historical data misread as an idle system: a failed or skipped collector run leaves a day blank or near-zero in ST03N. Check TCOLL first, then SM37 for the collector job, before concluding the system had no load that day.
- Single-instance view in a multi-server landscape: reading only the local application server's data when load was actually spread across a server pool gives a partial and misleading picture. Switch to the aggregated/total view across instances before drawing conclusions about system-wide slowness.
- Average response time distorted by outliers: a handful of long-running RFC calls or batch steps can pull the average up while most dialog steps were fine. Always check the step count and maximum time alongside the average, not the average alone.
- Granularity loss over time: hourly detail is retained only for a limited rolling window; older periods are rolled up into daily or weekly aggregates. An incident from months back cannot be diagnosed at hour level in ST03N even if it could last week — plan to pull detail promptly after an incident.
- Partial-day distortion after a restart: an instance restart clears the in-memory buffer, so 'today' figures right after a restart understate genuine load for that day. Do not compare a post-restart partial day directly against a full prior day.
- Reflex fix that makes it worse: repeatedly kicking off the collector job manually to 'fix' a gap without checking why it failed just produces another partial or duplicate aggregation; find and fix the root cause of the failed run first.
Whose problem this is
Basis owns ST03 and the collector jobs behind it. Functional teams typically raise the initial ticket ('users report slowness at 14:00') but should hand it over with the exact transaction or program, the affected users, and the precise time window, since ST03N analysis without a specific window turns into an unfocused fishing exercise.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/st03ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.