# SyteLine Background Tasks Stuck or Not Processing > Source: https://netray.co/erp-help/syteline-background-task-stuck-not-processing > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Background tasks stall for four main reasons: the processor service is not running or points at the wrong configuration, a task is flagged Running from a crash and blocks its own next run, the account it runs as cannot log in, or the work is blocked in SQL. Check the processor first, then task status and history, then the run-as user, then SQL. ## Kind error ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module Background Task Processing ## Query SyteLine background task stuck running not processing queue ## Alternate Queries - SyteLine background task processor not running - SyteLine background task status stays waiting - SyteLine scheduled task did not run overnight - CloudSuite Industrial background task history error ## Applies To Infor SyteLine 8.x and CloudSuite Industrial (form and service names vary slightly by release; on-premises and customer-managed environments) ## Steps ### How to get stuck background tasks moving **Items:** - Open the background task status and history forms for your release and note the state, last start and last message for the task. - Verify that the background task processor is running on the application server (Windows service or process) and that it points at the correct site and configuration. - Check the processor log or event log for authentication, license or connection errors at the time the task should have run. - Confirm the run-as user is active, not locked, has a password that has not expired, and holds the required permissions and a license. - If a task shows Running but the processor was restarted or crashed, reset or end that task entry so the next schedule can start. - Check SQL for blocking on the tables the task touches; a task waiting on a lock looks hung. - Run the task once manually from its form to see the real error message in the foreground. - After it succeeds, watch the next two scheduled runs before you close the incident. ## Sections ### Start with the processor, not the task **Body:** A surprising number of cases are simply that nothing is polling the queue. A server patch reboot, a service account password change, a moved application server or a second environment copied from production can leave the processor stopped or running against the wrong database. Tasks then sit in Ready or Waiting forever and the history shows no recent attempts at all. If history shows attempts that fail, the message in that row is your best clue. Authentication failures, license limit messages and connection timeouts each point to a different fix, and are often visible without reading any log file. If there is no history row for the missed run, the processor never picked it up. ### Tasks that say Running but are not **Body:** When the processor or its server dies mid-task, the status can remain Running. Many task definitions refuse to start a new instance while one is still marked running, so every later schedule is skipped silently. The cure is to clear the stale entry using the supported form, then confirm no real process remains before you do so. Check how long the task normally takes. A cost rollup or MRP job that legitimately runs for hours should not be reset because it looks old. Compare with earlier history durations. Only reset when the start time is far beyond normal or the processor has clearly restarted since it began. **Code:** -- Is anything on the SQL side still working for the task's login? SELECT s.session_id, s.login_name, s.status, s.last_request_start_time, r.wait_type, r.blocking_session_id FROM sys.dm_exec_sessions s LEFT JOIN sys.dm_exec_requests r ON r.session_id = s.session_id WHERE s.login_name = 'BackgroundTaskLogin'; -- replace with your service login ### Run-as user and environment issues **Body:** The account that runs the task is the one most often forgotten. An expired password, a disabled directory account, a removed license or a change in group membership can break every scheduled task at once. If several unrelated tasks failed on the same date, suspect the account before suspecting the tasks. Also review the dependencies between jobs. A nightly sequence where posting, MRP and reports must finish in order can stall if one step overruns into the next window. Add monitoring that alerts when expected tasks have no completed history row by a given hour, instead of discovering the gap when users complain. ## Pitfalls - Resetting a task that is genuinely still running and starting a second instance of a heavy job. - Editing the schedule when the real problem is the processor service being stopped. - Forgetting that a copied test environment may point its processor at production data. - Using a personal user as the run-as account; it breaks when that person leaves or changes password. - Closing the incident after one success without watching the next scheduled runs. ## Ai Angle SyteRay can read task definitions, status and history and answer "which scheduled tasks missed their last run and why" in one place, quoting the history message. It can correlate the gap with a service restart, a password change date, or SQL blocking at that time. Resetting tasks or restarting services stays with an administrator. ## Faq ### Why does a task stay in Ready and never start? **Answer:** Usually because no processor is polling for it, or the processor is attached to a different configuration or site. Check the service, its target database and its log. If history has no attempt recorded for the missed time, the task was never picked up. ### Is it safe to reset a Running task? **Answer:** Only if you are sure the work is no longer running. Confirm the processor restarted or crashed, and check SQL for sessions from the task's login. If work continues, resetting can start a duplicate instance and double-post or conflict on locks. ### Why did all tasks fail on the same night? **Answer:** A shared cause is likely: the run-as account expired or was disabled, a license limit hit, the application server restarted after patching, or the database was unavailable during backup or maintenance. Look at the earliest failure message and the infrastructure change calendar. ### How do I get alerted when a task misses? **Answer:** Build a simple check that compares expected task completion against history and sends an email when a required task has no completed row by a deadline. You can do it with a SQL Agent job or a SyteLine event, and test it by disabling a harmless task. ## Search terms syteline background task stuck, syteline background task processor, syteline scheduled task not running, background task history syteline, cloudsuite industrial background tasks, syteline task stays running, syteline task run as user, syteline nightly job failed --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json