# SAP Short Dump TIME_OUT: Maximum Runtime Exceeded > Source: https://netray.co/erp-help/sap-short-dump-time-out-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A TIME_OUT runtime error means a dialog (or RFC) work process ran longer than the maximum allowed runtime, controlled by profile parameter rdisp/max_wprun_time (600 seconds by default). The fix is almost always to move the long-running work to background processing or tune the underlying program, not to raise the timeout. ## Kind error ## System sap ## Erp SAP ERP (ECC 6.0 / S/4HANA) ## Module Basis / ABAP Runtime ## Query SAP runtime error TIME_OUT short dump ## Alternate Queries - how to fix TIME_OUT dump SAP - SAP dialog process time out error - ST22 TIME_OUT maximum runtime exceeded ## Applies To SAP NetWeaver Basis 7.x and S/4HANA (ABAP stack), all dialog and RFC work processes ## Steps ### Diagnose and resolve a TIME_OUT dump **Items:** Open ST22, find the dump, and read the program, include and line number under 'Where terminated', plus the runtime figure under 'What happened'. If it is reproducible, watch SM50 (or SM66 across the system) while the process runs to see the work process status, current ABAP statement and whether it is CPU-bound or waiting on the database. Trace the actual bottleneck with ST05 (SQL trace) or SAT (runtime analysis) for the failing program to find the specific statement consuming the time. If the process is really a report being run online, switch it to background execution (SA38/SE38 with F9 or SM36) since background work processes are not bound by the same dialog runtime limit. If it is a genuine slow SQL statement, optimize it - add missing WHERE conditions, avoid SELECT statements inside a LOOP, or add a secondary index with Basis/DBA involvement. Check SM12 for lock entries and the database for blocking sessions - a TIME_OUT can be the visible symptom of a lock wait or deadlock retry loop rather than pure CPU time. Only after ruling out the above, and with Basis approval, consider raising rdisp/max_wprun_time - understand this is a system-wide dialog parameter, and for Fiori/OData timeouts you also need to check the relevant ICM/HTTP parameters separately. Retest and confirm in ST22 that the dump does not recur, then check SM21 for related warnings around the original dump time. ## Sections ### What TIME_OUT protects against **Body:** SAP's dispatcher enforces a maximum runtime per dialog work process so a single long-running screen or report cannot monopolize a work process and back up the dialog queue for every other user. When a dialog process exceeds rdisp/max_wprun_time (600 seconds by default), the kernel kills it and raises a TIME_OUT runtime error by design. This is not a bug to work around by simply increasing the number; it is a resource protection mechanism, and the correct response is almost always to change how or where the long work runs. ### Diagnosing the real cause **Body:** Start in ST22 for the exact program, include and line, then reproduce with SM50/SM66 open to watch the work process live. If the process shows a long-running SQL statement, an SQL trace with ST05 (or SAT for a full runtime analysis) usually pinpoints a missing index, a nested SELECT inside a loop, or a poorly filtered query returning far more rows than expected. Custom Z-reports doing row-by-row processing (SELECT inside a LOOP instead of a single set-based statement) are the single most common cause seen in practice, followed by missing indexes on custom Z-tables. **Code:** - ST22 -> select dump -> 'Where terminated' tab for program/include/line - SM50 or SM66 -> filter to the failing user/program while reproducing - ST05 -> Activate trace -> reproduce -> Display trace, filtered by duration ### Background versus dialog execution **Body:** Background (BTC) work processes are not subject to the same wall-clock cutoff as dialog work processes, which is exactly why a report can time out when run online but succeed cleanly when scheduled as a background job through SM36 or executed with F9 from SA38. For genuinely interactive transactions that cannot be backgrounded, the real fix is performance tuning of the program or its data volume, not a longer timeout. ### When TIME_OUT is actually a lock or contention problem **Body:** Sometimes the dump is the visible symptom of the process waiting on an ABAP/Enqueue lock held by another session, or the database engine repeatedly retrying a deadlocked transaction. Check SM12 for outstanding lock entries against the same object, and check the database's own blocking-session view if locks look clear on the SAP side. A TIME_OUT occurring during an update task (V1/V2) points to different update-task tuning, not the dialog rdisp/max_wprun_time parameter, so confirm which work process type actually dumped before choosing a fix. ## Pitfalls Raising rdisp/max_wprun_time system-wide masks the underlying bad code and can let the dialog queue back up further under load, delaying unrelated work for other users. Fiori/OData and other HTTP-based timeouts are governed by separate ICM parameters, not just rdisp/max_wprun_time - changing one without the other fixes nothing for web-based calls. A TIME_OUT during an update task (V1/V2) needs different tuning than a dialog-triggered one; treating them the same wastes effort. SELECT statements inside ABAP LOOPs against large tables are the most common root cause and are easy to miss in a quick code review - trace it, do not guess. Reproducing intermittently (only under load) usually points to lock contention or resource pressure, not a consistently slow statement - check SM12 and system load, not just the code. ## Ai Angle ERPray grounded on your SAP Basis and ABAP layer can correlate an ST22 TIME_OUT dump with the relevant SM50 snapshot and known-slow-statement history in one query, surfacing whether a given dump is a code problem, a lock wait, or a genuine background-candidate report - cutting the usual ST22/SM50/ST05 hop between transactions. ## Faq ### What is the default value of rdisp/max_wprun_time? **Answer:** 600 seconds (10 minutes) is the common default, though it can be set differently per system. Check the actual value with transaction RZ11 rather than assuming the default is in effect. ### Will running the report in background always avoid TIME_OUT? **Answer:** Background work processes are not bound by the dialog runtime limit, so most long-running reports succeed there, but an extremely slow or looping program can still be killed by other limits (job runtime restrictions, database timeouts) if the underlying code is not fixed. ### Can end users fix a TIME_OUT dump themselves? **Answer:** No - it requires either a Basis/ABAP investigation into the actual bottleneck or a change to how the transaction is executed (for example, scheduling it in background). End users should report the dump number and time to Basis rather than retrying repeatedly. ### Is TIME_OUT the same for RFC calls? **Answer:** RFC calls run in their own work process pool and are also subject to runtime limits, though the relevant parameters differ slightly from pure dialog processing. The diagnostic approach (ST22, then SM50/ST05) is the same. ## Search terms SAP TIME_OUT short dump, ST22 TIME_OUT, rdisp/max_wprun_time, SAP maximum runtime exceeded, SAP dialog process timeout, ST05 SQL trace, SM50 work process, SAP background job timeout, SAP runtime error fix, SAP performance tuning ABAP --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json