---
title: "IFS Cloud Background Jobs: Design for the Night They Fail"
date: 2026-10-28
description: "IFS Cloud background jobs, batch queues and scheduled tasks: how to inventory, sequence and monitor them so a night failure is seen by morning."
author: "Dariusz Myśliwiec"
categories:
  - name: "How IFS Cloud ERP Transforms Business Operations Supply Chain AI and Legacy System Migration"
    url: "https://ifs-erp.consulting/ifs-cloud.md"
tags:
  - name: "IFS Cloud"
    url: "https://ifs-erp.consulting/tags/ifs-cloud.md"
  - name: "Go-Live"
    url: "https://ifs-erp.consulting/tags/go-live.md"
  - name: "IFS Cloud Implementation"
    url: "https://ifs-erp.consulting/tags/ifs-cloud-implementation.md"
  - name: "Best Practices"
    url: "https://ifs-erp.consulting/tags/best-practices.md"
  - name: "Architecture"
    url: "https://ifs-erp.consulting/tags/architecture.md"
---

# IFS Cloud Background Jobs: Design for the Night They Fail

Independent IFS Cloud practice · Operations design

 
## IFS Cloud background jobs: know every morning what ran last night

 **IFS Cloud background jobs** are tasks the system runs outside a user’s session: planning runs, postings, clean-ups and integration work. They are built once, pass in test, and are then forgotten, until a data volume grows, two heavy jobs collide or a schedule is wrong. The first sign is usually a downstream process that did not run, and by then a planning result, a posting or an interface is a day late.

  **Key takeaways**

 
- A background job is work the system executes outside a user session. A scheduled task is the recurring definition that creates such jobs on a timetable.
- A batch queue limits how many jobs run in parallel, so one long job in a single-process queue holds back every job behind it.
- Every job needs a row in an inventory: job and purpose, source, schedule, queue, owner, what it depends on, who needs it and by when, and expected duration.
- Heavy jobs are sequenced by dependency and separated into different queues, then re-timed when data volumes change.
- A named person runs a morning check with an escalation rule, and the handover package to support contains the inventory.

  ## 1.What is a background job in IFS Cloud, and how does it differ from a scheduled task?

 A background job is a unit of work that IFS Cloud executes on the server instead of in the window of the user who asked for it. A scheduled task is a definition that says when, and how often, such a job should be created. The task is the timetable and the job is one run of it.

 
### Where a job comes from

 Three sources create jobs, and each has a different owner:

 
- **A user action:** a user starts an operation that the system runs in the background. The owner is that user, who may never look at the result again.
- **A scheduled task:** someone configured a recurring run, for example a planning run. The owner should be a named person, and often is nobody.
- **An integration:** an interface posts work that IFS Cloud processes later. The owner is the interface owner, who sees the symptom only at the other end of the interface.

 
### Batch queues and why they exist

 A batch queue is a lane that jobs wait in before they run. Each queue runs a configured number of processes at the same time, which is how load is spread: heavy planning work can wait in one queue while short postings flow through another. Read the queue definitions in your own environment before you design anything, because every sequencing decision below depends on them.

  ## 2.How do queues, processes and execution plans interact?

 A job starts when its queue has a free process and when the queue is set up to run it. Two settings therefore shape the behaviour you see: the number of processes in the queue and the plan that governs when the queue takes work.

 In a queue with one process, a job that runs for three hours holds back everything behind it for three hours, including a posting job that takes seconds. Putting short, time-critical work in its own queue removes that dependency.

 When a job does not start, or stays running without finishing, begin with the queue definition and its plan, then with the job’s own parameters. A business user can see the status of a job but not why a server process stopped. That part belongs to whoever runs the infrastructure, which depends on your hosting arrangement. Agree it before go-live, as one line in the support agreement. A job that fails because of custom code needs a different diagnosis, described in [debugging silent custom code failure](https://ifs-erp.consulting/ifs-cloud/debugging-silent-custom-code-failure).

  ## 3.Which jobs should be on your inventory before go-live?

 The inventory should list every job that runs without a person watching it, in three groups: jobs you configured, jobs delivered with the application, and jobs created by integrations. The second group is the one that gets skipped, because nobody on the project created it. Planning runs such as MRP are typical members of the first two groups, and the [article on dynamic structures in MRP](https://ifs-erp.consulting/ifs-cloud/dynamic-structures-mrp) shows where one such run enters the picture.

 Each row of the inventory carries eight fields:

 
| Field | Question it answers |
| --- | --- |
| Job and purpose | What does it do, in one sentence a business owner would recognise? |
| Source | Configured by the project, delivered with the application, or created by an integration? |
| Schedule | When does it start, and what is the time zone of that schedule? |
| Queue | Which queue does it run in, and which other jobs share that queue? |
| Owner | Who checks the result, and who is the stand-in? |
| Depends on | Which job or interface must have finished before this one starts? |
| Needed by | Which process, report or person needs the result, and by what time? |
| Expected duration | How long does a normal run take, so that a run twice as long raises a question? |

 The “Depends on” and “Needed by” columns turn a list into a dependency map. If a posting job needs an inbound interface to finish first, the map shows that a late interface stops two things, not one.

  ## 4.How do you sequence heavy jobs so they do not collide?

 Heavy jobs collide when they start in the same window against the same data, and the cure is to order them by dependency and separate them by queue. Four rules apply:

 
1. **Order by dependency.** A job starts after the job whose result it reads, with a gap that exceeds the longest run you have observed.
2. **Separate by weight.** Long planning work and short transactional postings use different queues, so a long run cannot hold a short one back.
3. **Keep clear of the maintenance window.** A job that overlaps the slot used for updates risks being stopped or delayed at the worst moment. The slot is covered in [the IFS Cloud update calendar and maintenance windows](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-update-calendar-maintenance-windows).
4. **Re-time when volume changes.** A schedule that fits the pilot data may not fit after a second site goes live or after an acquisition adds orders. Review durations after each such event.

 Test the schedule with the volumes of a normal peak day, because a plan that works on migrated test data tells you little about the night after month-end.

  ## 5.How do you see job health without logging into a server?

 ### What the customer can see

 What you can see depends on your cloud arrangement, and that is a design question to put to your provider during the project: which job statuses can a key user read, and which monitoring views does the provider expose? Write the answer into the inventory. If the honest answer is “only the status of a job in the application”, the morning check below is built on that and nothing more.

 
### A morning check with an owner

 A morning check takes minutes when the inventory already says what to look for:

 
1. The named checker opens the job list and compares it with the inventory: every expected job is present.
2. Any job in an error status, or still running beyond its expected duration, is raised the same morning.
3. The checker confirms the result that matters to the business, for example that the planning output exists for today.
4. An exception goes to the job owner. If the owner does not answer within the agreed time, it goes to the stand-in, then to the support lead.

 This routine exists because one person who knows the jobs by heart is a single point of failure. The pattern is described in [single point of failure in the IFS supply chain](https://www.ifs-erp.com/en/blog/single-point-of-failure-supply-chain-ifs), and the way unattended work erodes after go-live in [process drift after go-live](https://www.ifs-erp.com/en/blog/process-drift-after-go-live-ifs-cloud).

  ## 6.What belongs in the handover package for scheduled jobs?

 The handover package for scheduled jobs contains the inventory, the dependency map, the morning check with its owner and escalation rule, and the contact for the infrastructure side. Without these, support inherits jobs that run but cannot tell which ones matter. The wider package is described in [the handover to support](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-handover-to-support), and the first weeks of live running in [hypercare after go-live](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-hypercare-after-go-live), which is the period in which a new schedule meets real volume for the first time.

  ## 7.What does a job design checklist look like?

 Use these eleven checks before go-live and again before each release update:

 
1. Every job, including jobs delivered with the application and jobs created by integrations, is in the inventory.
2. Every job has a named owner and a named stand-in.
3. Every job has an expected duration measured on realistic volume.
4. The dependency map shows what each job waits for and who needs its result.
5. Short transactional jobs and long planning jobs run in different queues.
6. The number of processes per queue has been reviewed against the jobs that share it.
7. No two heavy jobs write to the same data in the same window.
8. No job overlaps the maintenance window.
9. The morning check is written down, with the time it runs and the person who runs it.
10. The escalation rule names who is called when the owner does not answer.
11. The inventory is part of the handover package and has a review date.

  ## 8.Frequently asked questions

 What is the difference between a background job and a scheduled task in IFS Cloud? A background job in IFS Cloud is one run of work that the server executes outside a user session. A scheduled task is the recurring definition that creates such jobs on a timetable. A job can also come from a user action or from an integration, so the job list shows more than the scheduled tasks you configured.

   What is a batch queue and why would I use more than one? A batch queue in IFS Cloud is a lane in which background jobs wait and run, with a configured number of processes working at the same time. A second queue keeps short, time-critical jobs such as postings from waiting behind a long planning run.

   Why did my scheduled job not start or stay running without finishing? A scheduled job in IFS Cloud that does not start or stays running without finishing is diagnosed from the queue definition and its plan first, then from the job’s parameters. Whether a server process stopped cannot be seen from a business user’s window, so that check belongs to whoever runs the infrastructure under your hosting arrangement.

   Who should own scheduled jobs after go-live, IT or the business? Each scheduled job in IFS Cloud needs a business owner who judges whether the result is right and a technical contact who keeps the job running. The business owner is the person who needs the output, for example the planner for a planning run. Where only IT is named, a job that finishes with an empty result looks healthy and nobody notices.

   How do I know that every scheduled job ran last night? Compare the job list in IFS Cloud each morning with the job inventory: every expected job is present, none is in an error status, and none is still running beyond its expected duration. Which monitoring views you can open beyond the job list depends on your cloud arrangement, so ask your provider and record the answer in the inventory.

  ## 9.About the author

 **Dariusz Myśliwiec**: 18 years hands-on with IFS, including IFS Cloud. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.

 IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.

  ## Ask three questions about last night

 Can you list every job that ran last night? Does each one have a named owner? Do you know what stops when one of them does not run? Each “no” is a gap in the inventory.

 [Book a review of your scheduled-job inventory](https://ifs-erp.consulting/contact) [Read about the handover to support](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-handover-to-support)