Job queues in Business Central: monitoring, stuck jobs, and restarts that are safe

System admin · 11 min read

Background work is invisible until it stops. A Business Central job queue entry that failed overnight does not announce itself at the till — it shows up later as stale data, a sync that never ran, or a close that does not tie out. This guide is the admin routine for a retail org: which queue you are actually looking at, what every status means, how to monitor in minutes, and how to restart an entry without making things worse.

Two queues, two tools: do not mix them up

Retail installs run background work in two different places, and the first diagnostic step is knowing which one owns the job that stalled.

Business Central job queue entries live on the Job Queue Entries page. Each entry runs a specific report or codeunit, either once or on a recurring schedule — scheduled reports, background posting, and scheduled synchronisation with other applications all run this way. Everything in this article is about these entries.

LS Central replication is a different mechanism. LS Scheduler jobs move data between head office and stores, traditionally through the Data Director, whose jobs are watched in the Data Director Job Monitor — a separate tool, not the Job Queue Entries page. LS Central also offers web replication, where the scheduler job sends its request to an internal Business Central web replication module instead of the Data Director. If the missing data is store replication data, start in the LS tooling; if a Business Central report, posting job, or sync entry stalled, start on the Job Queue Entries page. Checking the wrong queue is the most common reason a “stuck job” takes an hour to find. (For what happens at the terminal itself when connectivity drops, see POS offline mode.)

The status decoder

Every job queue entry carries a status, and the status — not the age of the entry — decides what to do next. Microsoft documents seven values:

Two traps hide in that table. First, On Hold does not stop a running job: once a job starts it runs until it completes, whatever you change on the entry. If a running job genuinely must be stopped, that is a manual intervention — for example, stopping the corresponding session — not a status change. Second, a crashed job may not be on the Job Queue Entries page at all. In one documented incident, an integration sync job had crashed and blocked re-running, but the job was missing from the queue because it had been triggered manually from its setup page rather than scheduled; the integration sync view was only a log of runs. If the entry is not in the queue, it is not running on a schedule — find where it is triggered from before trying to restart it.

A monitoring routine that takes minutes

Monitoring works when it is a habit, not an investigation. Three built-in surfaces do the job:

• The Job Queue Tasks cue on the home page shows three tiles: Tasks Failed, Tasks in Process, and Tasks in Queue. A task lands in Tasks Failed only after it exceeds the maximum number of attempts set on the entry, so a non-zero failed tile always means an entry needs a human. The cue can use coloured indicators, which makes a red tile hard to walk past.
• The My Job Queue part shows entries you started that are not finished, flags errors on documents posting in the background, and lets you cancel a document posting. It is not on the home page by default; add it through personalisation if background posting matters in your org.
• Failure notifications. The Set Up Job Queue Notifications assisted setup chooses who gets told when an entry fails — the person who started it, job queue administrators, or both — and how: in-product notifications on the home page, or an external business event driving a Power Automate flow subscribed to the Job queue task failed event. Notifications can fire immediately or only after a threshold of failures, and they can be switched off on the My Notifications page. Set this up once; afterwards a failed entry finds you instead of the other way round.

The routine itself: glance at the cue daily, and once a week open the Job Queue Entries page and sort by status. Anything in Error gets the restart procedure below. Anything Ready with an earliest start time well in the past gets a look at the Scheduled Tasks page, which lists every scheduled task and the company each runs in — Microsoft notes that a job’s start can slip when there are many entries and tasks in the environment, and that all scheduled tasks stop in an environment that is a copy of another one until they are set ready there. That last point catches out sandbox refreshes and environment copies every time.

Safe restart procedure

Restarting is the documented first response to an entry in Error — job queue entries stop running when an error occurs, and they do not recover on their own. Safe means restarted after a two-minute diagnosis, in this order:

1. Read the error before touching anything. On the entry, choose Show Error. Then open the entry’s Log Entries to see the run history in the Job Queue Log Entries. Note whether this is the first failure or the latest of many.
2. Classify the cause. A connection failure to an external service that was temporarily unavailable is a restart candidate. A data or code error that will fail identically in two minutes is not.
3. Check the retry settings. Look at Maximum No. of Attempts and Rerun Delay (sec.) on the entry. If attempts remain, the entry may still be cycling on its own — do not restart over the top of it.
4. Restart once. Set the entry status to On Hold, then to Ready — or use the restart action directly. One restart, then watch.
5. Watch the next run complete. Confirm the status leaves In Process, the log shows a clean run, and for a recurring entry the earliest start time has rolled forward to the next scheduled run.
6. Verify the business result, not just the status. Whatever the job was supposed to produce — the report, the posted documents, the synchronised records — check that it actually exists. A green status with missing output is still an incident.

What success looks like: the entry completes a full run with no new entry in the Job Queue Log Entries marked as an error, the Tasks Failed tile is back to zero, and the downstream data the job feeds is current. If the restart fails with the same error, stop restarting — the next section applies.

When restarting is the wrong move

If a restart does not help, Microsoft’s guidance is that the issue might be in the code. The Job Queue Log holds the AL stack trace for the failed run, and the stack trace identifies the owner — also called the publisher — of the code. Route by owner: an error from an app or extension goes to your Microsoft partner; an error from a Microsoft application goes to a Microsoft support request. Either way, send the same three things: the ID of the job queue run where the error occurred, the timestamp of the error, and your timezone. On Business Central version 22.1 and later, the Copy details action on the Job Queue Log Entries page copies exactly that information; on earlier versions, send a screenshot of the page. Gathering this before opening the ticket is the difference between a one-round fix and a week of back-and-forth.

Also resist restarting in two other situations. An entry stuck In Process far beyond its usual runtime is not fixed by a status change, because On Hold does not affect a running job. And an entry in Waiting behind a long-running entry in the same category is queued by design — restarting the category leader, not the waiter, is the only lever, and only if the leader is genuinely stuck.

Recurrence hygiene

Most chronic job queue problems are setup problems. Four settings deserve a quarterly review:

• Maximum No. of Attempts and Rerun Delay (sec.). Together these decide whether a transient failure self-heals. The attempts field sets how many times an entry can fail before it stops trying; the delay sets the seconds between attempts. For entries that talk to external services, a few attempts with a real delay can keep the entry running until the service comes back — instead of a hard stop at 2 a.m. that nobody sees until the close.
• Interval length. Recurring entries can affect performance, and Microsoft’s advice is to use the largest interval the business can tolerate: before setting a five-minute recurrence, ask whether fifteen minutes or hourly would do. In a retail org, also weigh when the job runs against when stores are trading and closing.
• Categories. Entries sharing a category code run one at a time, in sequence. That is the right design for jobs that must not overlap, and a mystery backlog when unrelated jobs were categorised together by accident.
• Permissions. Creating an entry is not the same as running one. Holders of the SUPER permission set can run all objects included in the license, and delegated administrators can create and schedule entries — but only administrators and licensed users can actually run them. An entry created by a delegated admin that never runs is a permissions shape, not a queue fault.

For larger estates, administrators can also monitor the job queue with Azure Application Insights telemetry and alert on it — worth setting up once the basics above are boring. And keep the surrounding routine honest: a job queue that silently failed is often how a statement ends up short, so the queue check belongs in the same habit as the end-of-day statement routine.

FAQ

A job failed at night and the data is stale this morning. Restart or investigate?
Read the error first. If it is a transient connection failure and retry attempts are exhausted, restart once and verify the business output. If the error is a data or code error, restarting reproduces it — gather the run ID, timestamp, and timezone and route it by publisher instead.

An entry says Waiting and its start time has passed. Is it stuck?
Not necessarily. Waiting only appears on entries with a category code, and it means the entry is scheduled while another entry in the same category runs. It becomes Ready when that entry finishes. It is only stuck if the entry ahead of it is stuck.

Does putting an entry On Hold stop a job that is already running?
No. On Hold prevents an entry from starting at its scheduled time; a job that has already started runs until it completes regardless of changes to the entry.

Who should own job queue failures in a retail org?
Whoever the failure notifications point at. Set up notifications to reach the job queue administrators (and optionally whoever started the entry), so the first failure of the day is seen by a named person rather than discovered at the close.