# IFS Cloud Background Job Stuck in Posted or Executing > Source: https://netray.co/erp-help/ifs-cloud-background-job-stuck-posted-executing > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A background job that stays Posted is waiting for a batch queue processor that is not picking it up, while one that stays Executing is either genuinely long-running or orphaned after a crash or restart. Check the Background Jobs page for the job state and error text, confirm the batch queue is active with capacity, then requeue or cancel the job. ## Kind error ## System small-erp ## Erp IFS Cloud ## Module Administration / Background Jobs and Batch Queues ## Query IFS Cloud background job stuck in Posted or Executing ## Alternate Queries - IFS background job not running batch queue - IFS Applications background job error how to restart - IFS Cloud scheduled task not executing - IFS batch queue processor not picking up jobs ## Applies To IFS Cloud and IFS Applications 10; the Background Jobs and Batch Queues pages exist in both, with different navigation and client styles ## Steps ### How to diagnose a stuck background job **Items:** - Open the Background Jobs page and filter by the job description or the user who posted it. Note its state, queue and posted time. - Open the job detail and read the error text and the call stack if present. Many jobs that look stuck have actually failed. - Open Batch Queues and confirm the queue the job belongs to is active, and that it has at least one processor or execution slot. - Check whether other jobs on the same queue are Executing. One long job can block a single-slot queue and leave the rest Posted. - If the job is orphaned after a restart, cancel it, then post it again, rather than repeatedly editing its state. - For recurring work, open the schedule that posts it and confirm the schedule is active and not creating duplicates. - Raise concurrency or move heavy jobs to a dedicated queue if they regularly starve small ones. ## Sections ### Posted versus Executing: different problems **Body:** A job is Posted when it has been queued but no processor has started it. The usual causes are an inactive or misconfigured batch queue, a queue with no free execution slots because a long job holds them, or an application server whose batch processing is not running after an upgrade or restart. A job is Executing while a database session runs it. If the session has died, for example after a node restart, the row can remain Executing with nothing behind it. Compare the job start time with how long it normally takes, and check whether a database session for it still exists before assuming it is slow. ### Reading the failure instead of guessing **Body:** IFS background jobs run PL/SQL methods, and when they raise an error the message is stored against the job. Typical failures are business-rule errors from the logical unit (a missing period, a locked record), Oracle errors such as a resource busy condition from contention with online users, and permission problems because the job runs as the posting user. That last point is easy to miss. A job posted by a user whose permissions were later removed, or who has left the company and been disabled, can start failing without any code change. Identify the posting user and verify they are still valid. ### Queues, schedules and concurrency **Body:** Queues give you control over parallelism. Putting a nightly financial posting and a frequent small inventory job on the same single-slot queue guarantees the small job waits. Create separate queues for different workload classes and size them to the database, not to optimism. Schedules post jobs at intervals. If a run takes longer than the interval, you can accumulate Posted copies of the same job. Look for the same description appearing many times, and consider adding logic or intervals that prevent overlap. ### Safe recovery and what not to do **Body:** Prefer the supported actions in the Background Jobs page: cancel, then post again or requeue. Directly updating the underlying job tables to flip a state can leave the processor and the table disagreeing, and on managed cloud environments you may not have that access anyway. Before rerunning, ask whether the job is idempotent. A half-finished posting job rerun blindly can duplicate transactions. For financial and inventory jobs, check what the first run already committed, then decide whether to rerun, partially rerun, or correct manually. **Code:** -- Read-only check of long-running sessions (needs DBA-level access, run by the person who owns the database) SELECT sid, serial#, username, status, last_call_et FROM v$session WHERE username IS NOT NULL ORDER BY last_call_et DESC; ## Pitfalls - Re-posting a job repeatedly while the original is still Executing, creating duplicate runs. - Assuming Executing means progress without checking whether a database session still exists. - Putting heavy and light jobs on one single-slot queue. - Ignoring that the job runs with the posting user's permissions, then wondering why it fails after a user is disabled. - Editing job tables directly to change state instead of using cancel and requeue. - Rerunning non-idempotent financial or inventory jobs without checking what was already committed. ## Ai Angle An assistant grounded in the IFS database and job metadata can answer the question people actually ask: which jobs are stuck, on which queue, posted by whom, and what error text the failed ones carry. ERPray can run that as a read-only query, show the SQL it used, and summarise patterns such as many Posted copies from one schedule. It does not cancel or requeue anything on its own; those actions stay with an administrator or go through human approval. ## Faq ### What is the difference between Posted and Executing in IFS? **Answer:** Posted means the job is queued and waiting for a batch queue processor. Executing means a processor has started it and a database session is, or should be, running it. A Posted job points at queue capacity or configuration; a long Executing job points at slow work or an orphaned session. ### Is it safe to cancel an Executing background job? **Answer:** Usually, through the supported cancel action, but check what the job has already committed first. Cancelling a long posting job mid-way can leave partial data. For finance and inventory jobs, review the results of the partial run before posting it again. ### Why did a job that worked yesterday start failing? **Answer:** Common causes are a changed or disabled posting user, a permission set change, locked records from online users, a closed accounting period, or data that now violates a business rule. Read the stored error text on the job, which usually names the logical unit and the rule. ### How do I stop a schedule creating overlapping jobs? **Answer:** Review the schedule interval against actual run time, place the job on a dedicated queue with limited slots, and, if needed, add a guard so a new run exits when the previous one is still active. Cleaning up duplicates alone will not fix the cause. ## Search terms IFS background job stuck, IFS batch queue, IFS Posted state background job, IFS Cloud scheduled task, IFS background jobs error, IFS Applications background job, IFS batch queue processor, IFS job requeue cancel --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json