Scheduling and the run

The frequency pattern itself is defined in the Toolkit; this doc covers how scheduling and build behave. See How workflows work.

Task walkthrough: Schedule a workflow. This page is the full configuration and troubleshooting reference.

Build turns a workflow definition into a concrete day's run. Frequencies decide which days and times a job is eligible, and calendars / working days remove days that don't qualify.

The workflow's workingDays and holiday calendars are not a filter applied after the fact — they are inputs to the frequency calculation itself, which is why the workflow editor's Forecast view and the build agree. The forecast in the Frequencies dialog is a separate, simpler preview and can differ — see Forecast. See Working days and non-working days.

Build settings (per workflow)

Setting	Notes
daysInAdvanceToBuild	The offset of the first date built — 0 is today, 1 is tomorrow. Accepted range 0–365.
daysToBuild	How many consecutive dates are built, starting at that offset. daysInAdvanceToBuild: 1 with daysToBuild: 3 builds tomorrow, the day after, and the day after that.
buildTime	Time of day the build runs (HH:mm). The automatic build does not use this — see Automatic daily build.
buildOnHold	When on, the run is built on hold and won't run until released.
overwriteOnBuild	Whether a rebuild overwrites the existing run. Read Automatic daily build before leaving this on for an unattended build.
deleteAfterDays	Stored with the build settings, and not acted on: nothing removes old instances automatically, whatever the value. It is not shown in the workflow editor. A built instance stays until it is deleted or replaced by a rebuild.
additionalHolidayCalendar	A calendar whose dates are non-working days for this workflow. A reference that no longer resolves does not block an ordinary save — see Calendars.
useHolidayCalendar	Opts into a base (platform-wide) holiday calendar. This contributes no dates today — no calendar can yet be designated as the system holiday calendar, so on and off behave identically. Use additionalHolidayCalendar for holidays you want applied.
workingDays	The days of week the workflow treats as working days. This is the definition every working-day frequency rule counts against — there is no fixed Monday-to-Friday. Under a Tuesday-to-Saturday week, Saturday is a working day and Monday is not.
startTime	The workflow's start time (HH:mm).
conflictOtherDays	Conflict handling across schedule dates.
multiInstance (Allow Multi-Instance)	When on, the workflow builds once per named schedule instance rather than once per date. See Schedule instances.

When autoBuildSettings is null, the workflow has no build settings at all and every run of it is started by hand.

Automatic daily build

The platform can build workflow instances ahead of their date on its own, once a day, from each deployed workflow's own build settings — instead of every run being started by an operator.

Off by default in this build

The daily build sweep is disabled unless it is turned on for your environment. Until it is, build settings are stored and not acted on, and every build is one somebody asks for. Turn it on per environment after reviewing the settings on the workflows there: build settings have been authorable for far longer than anything read them, so values nobody has revisited since they were authored are exactly what the first unattended pass would act on.

One pass, at one time of day. The sweep fires once daily at a platform-configured local time and builds every qualifying workflow in that pass. A workflow's own buildTime is not consulted — it does not stagger the sweep, and setting it does not move when that workflow is built.

What the pass builds, per workflow:

1. The workflow must be deployed to the environment and carry build settings.
2. Its dates are daysInAdvanceToBuild through daysInAdvanceToBuild + daysToBuild - 1, counted from the day the pass runs.
3. Each of those dates must fall inside the deployment's own window. effectiveDate counts as in-window; expirationDate does not — a date on the expiration day is not built.
4. Each date then goes through the ordinary build: frequencies, calendars and working days decide what qualifies, exactly as they do for a manual build.

It never adds a repeat run. For a workflow that can hold several runs of one schedule instance for a date, an unattended pass always resolves to a run it already produced rather than allocating a new one. That is what keeps the pass idempotent across a redeploy that edits an instance property value — otherwise every already-built date would be built again in full, with every job running and no operator present.

It acts on the deployed settings. A transformation rule that rewrites autoBuildSettings for an environment is what the sweep reads there — so a rule that turns overwriteOnBuild off for production does take effect. A setting the sweep cannot read as a real number or a real boolean skips that workflow rather than being guessed at: a broken rule stops that workflow's builds visibly instead of quietly building the wrong dates.

Sub-workflows are skipped. A workflow marked as existing only to be run by a Workflow Container job is not built directly, by the sweep or by anyone else.

What an unattended rebuild will and won't replace

overwriteOnBuild makes the sweep rebuild a date that already has an instance, which deletes the existing instance and its jobs and builds a replacement. Unattended, that is deliberately narrower than the same request from an operator:

Existing instance status	Operator rebuild	Automatic rebuild
WAIT_TO_START, WAIT_CONTAINER_JOB, ON_HOLD, PARENT_HOLD — and the instance has never started	Replaces it	Replaces it
Any of those four, but the instance has already started	Replaces it	Left alone
COMPLETED	Replaces it	Left alone
CANCELLED	Replaces it	Left alone

The two terminal cases are excluded because an unattended pass cannot tell "this date already ran" from "this date is ready to run". Rebuilding a COMPLETED instance would re-run every job in it — transfers already sent, files already moved — and rebuilding a CANCELLED one would override an operator's decision to stop it.

Status alone is no longer the whole test. An automatic rebuild also leaves alone any instance that has already started running, whichever of the four statuses above it currently sits in. Status by itself can't tell the two apart, because several ordinary operator moves park a run that has genuinely done work in a status that looks untouched:

• A workflow held part-way through its run sits at ON_HOLD.
• A workflow reopened from COMPLETED with Hold or Release lands in ON_HOLD or WAIT_TO_START — the same statuses a run that has never started would be in.
• Restarting a job on a reopened instance moves it on again, into another status that reads as safe to replace.

In each of those the run's jobs have already done real work, so the sweep declines to overwrite it and counts it with the dates it left alone because they had already run. An operator rebuild is unaffected and still replaces any instance in an allowed status.

An unattended rebuild discards operator edits

Within the statuses it does replace, a rebuild loses what an operator did to a not-yet-started instance — jobs they added, holds they placed. That is what overwriteOnBuild asks for, and it is the reason to leave it off unless a workflow genuinely wants it.

After an outage

If the service is down across the daily fire time, it attempts the missed day when it comes back, rather than waiting for tomorrow and losing the night's builds. A start before that day's fire time is not a catch-up and does nothing — the scheduled pass is still ahead of it. Repeated attempts on one date are capped, so a service that keeps failing mid-pass cannot re-build the same dates on every restart.

Building a multi-instance workflow

A workflow with Allow Multi-Instance on builds once per named instance defined on it, so one definition produces PAYROLL_BRANCH1 and PAYROLL_BRANCH2 for the same date, each with its own property values. A build either names one instance or builds them all.

Build numbers are allocated per instance, so each instance has its own build 1 — the instance axis is separate from the rebuild axis, not a reinterpretation of it.

One instance can also be built more than once for a date. A build whose instance property values match no existing run of that name gets a new run rather than an "already exists" conflict; a build whose values match an existing run is that run, and behaves exactly as it did before. So a dated run is identified by three things — instance name, run, and build number — and only the third of them counts rebuilds. A repeat run is displayed as PAYROLL_BRANCH1$0002.

Turning Allow Multi-Instance on without declaring any instance is legal: the workflow builds as a single implicit Default instance. Such a workflow is repeatable on every build — because it declares no instance properties, there is no property set to match, so each build adds a run rather than colliding with the last. Earlier builds refused the second one with "Nothing was built — 1 already exists. Tick Overwrite Existing to replace it." See Schedule instances.

Schedule instances is the full reference: defining instances, naming rules, repeat builds, what overwrite deletes, the fan-out and per-instance caps, and how dependencies and events address one instance.

Holiday calendars now reach the build

A workflow's Additional Holiday Calendar is resolved to its dates and applied by both the workflow editor's Forecast view and the real build. Earlier builds ignored it entirely — the setting was stored and never sent, so it changed neither the preview nor the dates a workflow ran on. If you set one in the past and concluded it did nothing, check it now: it takes effect. The forecast in the Frequencies dialog does not apply it — see Frequencies.

Calendar resolution fails closed. If a workflow's holiday calendar or a frequency's exclusion calendar cannot be resolved, the build fails rather than proceeding with the calendar unapplied — running on a day you excluded is worse than not running. (An Annual Plan calendar is the exception: one that cannot be resolved gives the plan no dates, so its jobs simply do not build — see Annual Plan.)

caution

A build from Processes reports this only as Internal server error

When you schedule a workflow from Processes and one of those calendars cannot be resolved, the date is reported as Internal server error. The message does not name the calendar or say whether trying again could help. If a build fails that way, check that the workflow's Additional Holiday Calendar and each frequency's exclusion calendar still exist.

A frequency renamed after deployment stops the jobs attached to it

A deployment stores its workflow's frequency references by name. Rename a frequency afterwards and the deployed reference dangles: it is dropped from the build, and any job attached only to that frequency does not build. If every reference dangles, the workflow builds nothing until the deployment is repaired — redeploy it. Earlier builds substituted a stand-in daily pattern instead, which quietly shrank the build while still reporting the jobs as qualifying.

Per-frequency runtime settings (per job)

Each job frequency carries its own runtime behavior:

Setting	Notes
buildStatus	released, onHold, doNotSchedule, toBeSkipped, or disabled. A disabled build status turns off this frequency and leaves the job's others in play — it is not the job-level Disabled switch, which removes the job from the build entirely.
priority	Relative scheduling priority.
startTimeOffset (+ startTimeOffsetFormat absolute/relative)	When the job is eligible to start. Held as a setting in its own right, so editing it on a job instance survives a save and stays correct after a recurring restart.
lateToStartOffset	Threshold for late-to-start. No format of its own — it follows the start offset's.
lateToFinishOffset	Threshold for late-to-finish. No format of its own — it follows the start offset's.
latestStartOffset (+ latestStartOffsetFormat absolute/relative)	The latest allowed start. Its format is set independently of the start offset's.

All four offsets are now carried onto the built job instance, not just the start offset, so the Frequencies tab on a dated run shows the offsets the job was authored with. They cannot be measured back out of the resolved times, because those are anchored on the schedule's start — a tab that did the subtraction would show every deadline shifted by the start time, and shift it again on the next save. | maxRunTime | Minutes of run time after which the job is reported as having exceeded its limit. 0 means no limit. See Exceeding Max Run Time. | | estimatedRunTime (+ estimationSource calculated/history/userDefined) | Expected run time. | | failureRetries | enabled, maximumAttempts (1–999), minutesBetweenAttempts (0–1440). Both bounds are enforced when the workflow is saved, in the Code view, and when the setting is edited on a job instance — a budget larger than one of them is refused rather than stored. maximumAttempts counts retries, not total runs. See Failure retries. | | successReruns | none, recurringInstances (with instance times), or restartOffset (interval + max runs). See Success reruns. |

These offsets drive the job-status events (LateToStart, LateToFinish, MissedLatestStartTime) covered in Workflow events, and maxRunTime drives exceededMaxRuntime — the one trigger in that list that is a derived condition rather than a status. See Exceeding Max Run Time.

Start-time windows are anchored to the schedule date

A job's start-time window is an offset into its schedule date, not into today. A workflow instance built for the 14th has its windows, its planned start and its latest-start deadline all measured from the 14th — at the workflow's own start time on that date, not from midnight (see Offsets past midnight) — whichever day it happens to be when the job is evaluated.

This matters in two directions, and both used to be wrong when the window was measured from "today" instead:

• A job still waiting past midnight kept its window where it was, instead of having its already-elapsed start time pushed an hour into the future every night.
• A workflow built ahead for a future schedule date doesn't read as startable today, a day early.

note

If a workflow instance carries a schedule date the platform can't read, its windows fall back to being measured from today. That's logged as a warning.

Offsets past midnight

An offset is a duration from the workflow's start time on the schedule date, written HH:mm. It is not a clock time, and the distinction matters in two ways.

The base is the workflow's own start time, not midnight. A workflow that starts at 08:00 with a job whose Start Offset is 06:00 makes that job eligible at 14:00 on the schedule date. Read every offset as "this long after the schedule is planned to start".

This changed — offsets used to resolve from midnight

Earlier builds resolved all four offsets from midnight of the schedule date, so the job above became eligible at 06:00 — eight hours early, with nothing logged. Because a workflow's start time is required, almost every schedule was affected. A deadline you set before this change and found firing too early needs no repair in the definition; rebuild the schedule date to resolve it against the start time.

If a built instance carries a start time the platform cannot read, its offsets fall back to a midnight base and that is logged as a warning.

The hours field is not capped at 23, because it is a duration: a job that must start by 02:00 the morning after an 08:00 schedule is 18:00, and one that must start by 02:00 the second morning is 42:00. The field takes two digits with a ceiling of 99:59, minutes are 00–59, and both are zero-padded. Folding in the start time can therefore push a resolved window past 24 hours, which is what carries it onto a later day rather than opening it a day early.

Daylight saving

An offset that lands in the hour a spring-forward transition skips resolves forward: against a schedule starting 00:00 on the transition date, 26:30 is 03:30, never 02:30, and 26:30 and 27:30 collapse onto the same instant that date. On a fall-back date, an offset landing in the repeated hour takes the first of the two instants.

Five settings are durations and accept the full range:

Setting	Where
Start Offset	Offset Information
Late to Start Offset	Offset Information
Late to Finish Offset	Offset Information
Latest Start Offset	Latest Offset
Latest Runtime Offset	Success Reruns, when the mode is a restart interval

The first four are the ones measured from the schedule's start time. Latest Runtime Offset bounds a restart interval rather than naming a point in the day, so the base above doesn't apply to it.

Four nearby fields really are clock times or calendar settings, and stay bounded at 23:59, because each has a separate days field or is the base the offsets hang off: Predicted Start Time (paired with Predicted Start Days), a recurring instance Time (paired with its Days Offset), the workflow's build time, and the workflow's own start time.

note

00:00 means "not configured"

On Start Offset, Late to Start Offset, Late to Finish Offset and Latest Start Offset, 00:00 means the setting is not in use — not the schedule's start time. A genuine zero offset cannot be expressed on any of the four; use a small non-zero offset if you need one right at the schedule's start.

The build reads the value that way, and so does an edit on a job instance: 00:00 is never resolved into a deadline at the start of the day.

A timing offset already in force cannot be cleared on a job instance

Setting one of the four back to 00:00 on a job instance's Frequencies tab is refused, with a message naming the field: "Clearing Latest Start Offset on an existing job instance is not yet supported. 00:00 means 'not configured', and the time already resolved from it stays in force."

An earlier note here said clearing worked. It does not — and it did not before this change either. What changed earlier was only that a cleared offset stopped being resolved into midnight of the schedule date; the deadline already resolved from the old value stayed in the instance and went on being enforced, while the tab showed 00:00. The refusal replaces that silent disagreement with an answer. To remove a deadline from a dated run, clear it on the workflow definition and rebuild the schedule date.

The two Format controls

The Frequencies tab shows two absolute/relative Format controls, and each governs the offsets grouped with it:

• Offset Information — one Format over Start Offset, Late to Start Offset and Late to Finish Offset. Late to start and late to finish are measured from the resolved start time, so they inherit the start offset's format through it rather than carrying one of their own.
• Latest Offset — its own Format over Latest Start Offset, set independently of the start offset's.

Earlier builds attached the second control to late to finish, which has no format of its own, so the control read as setting something it did not set. A frequency saved before the change keeps working and needs no repair: the retired setting is accepted and ignored, and the current one is optional and treated as absolute when absent.

caution

Only the absolute format is honored

absolute means "measured from the schedule's planned start time", and that is how every offset now resolves — see Offsets past midnight.

relative would mean "measured from the schedule's actual start time", and it is not honored yet. The setting is stored, carried and shown, and an offset set to relative resolves against the planned start exactly as an absolute one does. On a schedule that starts late, that is the difference between the two. Until it is implemented, read every offset as absolute.

Recurring jobs and the latest-start deadline

A job set to recur sits in WAIT_START_TIME between its runs, and that parked state is owned by the recurrence. The latest-start deadline still ends it. A recurring job's Latest Start Offset bounds every run in its cycle, not only the first:

• When a run finishes after the deadline has passed, no further restart is scheduled — the cycle is over.
• A job already parked waiting for a restart when the deadline passes transitions to MISSED_START_TIME, which fires the matching event, releases its resource locks, and retires the rest of the cycle.
• A restart that comes due after the deadline is never dispatched.

The window's two ends therefore behave differently, and deliberately so:

Bound	Applies to
Start Offset — the earliest the job may run	The first start only. Scheduling a restart supersedes it; re-checking it on each restart would discard the rerun interval entirely, because an already-open window would advance the job on the very next sweep.
Latest Start Offset — the deadline	Every run. It is never superseded.

Earlier builds had both ends switched off for a restart. A job configured with both a run window and success reruns honoured the window on run 1 and then dispatched on its interval regardless of it, with no status, no log entry, and nothing an operator could have noticed.

This reverses an earlier exemption

A recurring job parked between runs used to be exempt from the deadline, on the reasoning that terminalizing it would cancel the rest of its cycle. Cancelling the rest of the cycle is the intended outcome: a deadline that a parked job is allowed to sit past is not a deadline. If you configured a Latest Start on a recurring job and observed it being ignored, it is enforced now.

Missed start time was never reached before

The deadline a job was built with never reached the running job at all, for jobs of every kind rather than only recurring ones — so MISSED_START_TIME was a status nothing could produce, however long a job waited past its Latest Start. That is fixed, with three consequences worth knowing before you rely on it:

• A job past its deadline is ended, not started late — at the gates where the deadline is checked. This applies to an ordinary job with no recurrence too: one released into WAIT_START_TIME after its deadline has already passed is left to be ended rather than advanced towards an agent. A job still waiting at a later gate when the deadline passes is a different case — see Where the deadline is checked.
• Restarting a missed recurring job gives you one run, not the rest of the cycle. The deadline retires the cycle, and a restart is a one-off rather than a request to re-arm the recurrence. Push the Latest Start out and restart, and you get a single run.
• An instance whose Latest Start was cleared before this change may end immediately. Clearing the field through the Frequencies tab used to store midnight of the schedule date, which is a deadline already in the past. The value was inert while nothing read it; now it is read, so such a job ends as MISSED_START_TIME on the first sweep. The editor cannot repair it — rebuild the affected schedule date. Exposure is limited to instances still resident on their own schedule date, so it clears itself.

Where the deadline is checked

The Latest Start deadline is checked only while a job is in one of these statuses:

• WAIT_START_TIME — waiting for its start time, or parked between runs or retries
• LATE_TO_START
• WAIT_TO_START — queued to start
• WAIT_JOB_CONFLICT

It is not checked while the job waits at an earlier gate — WAIT_JOB_DEPENDENCY, WAIT_THRESHOLD_DEPENDENCY, WAIT_RESOURCE_DEPENDENCY, WAIT_EXPRESSION_DEPENDENCY or WAIT_MACHINE. A job whose deadline passes there is not ended. When its last gate clears, it is normally queued and dispatched in the same pass, so it can start after its Latest Start rather than ending as MISSED_START_TIME.

If a late start must not happen, watch jobs still waiting at those gates near their deadline, and hold or cancel them yourself.

Holding a workflow suspends the deadline

While a workflow is held, its waiting jobs are not ended for missing their start deadline. A hold is how an operator buys time, and it used to cost the run instead: the hold stopped jobs being dispatched but nothing stopped the deadline being enforced, so a job whose Latest Start passed during the hold went terminal — MISSED_START_TIME, or FAILED for a job parked between failure retries — and releasing the hold did not bring it back. An operator could hold a workflow to investigate and find its jobs dead when they came back to it.

What to expect now:

• A held workflow raises no MISSED_START_TIME. This covers a job held directly and a job in a workflow held by an ancestor — the same reach a hold has over dispatch.
• The deadline itself does not move. It is measured from the schedule date, not from when the hold started, so a job whose Latest Start passed during the hold is ended on the first pass after you release. The hold defers the decision; it does not extend the window. If you need the job to run, push its Latest Start out before releasing.
• Late to Start still happens. It is advisory and the job can still start, so it is raised under a hold as it always was.
• A running job is unaffected. LATE_TO_FINISH and Max Run Time are about a job that is already going, and a hold does not reach it.

The same suspension applies to a workflow that cannot process jobs for any other reason — one that has been cancelled, or has completed — so a job still waiting in one is no longer ended at a deadline that can never be met.

Exceeding Max Run Time

A job that overruns its Max Run Time is now reported. In earlier builds nothing ever compared a running job's elapsed time against the limit: the value was authored, saved and carried onto the job, and no consumer read it — so a job could run past its limit indefinitely and finish reported as a plain success. Two things changed together, and the second is why the first was invisible.

A Max Run Time set in the job editor never reached the built job

The limit was written only when someone edited a job instance directly. A freshly built job carried no limit at all, so even a watchful engine would have had nothing to compare against. The frequency's Max Run Time now reaches every job the build produces, on all three build paths.

Check any job you set a limit on before this release. Its configuration was correct all along; the runs built from it carried nothing.

The overrun is a label, not a status, and the job is not stopped. The job keeps running to its natural end and earns whatever terminal status it would have earned. What happens is:

When it is detected	Within about a second of the job passing its limit. Measured from when the platform dispatched the job, not from when the agent started the process — so time the work spends queued on a busy agent counts toward the limit. This matches the behavior the Classic scheduler has always had: it also stamps its start at dispatch and never moves it when the agent reports the job running
Which jobs are checked	Every job that is genuinely running — including one already running past its late-to-finish threshold, and one with a kill already in flight. All three are still accruing time
How often it is reported	Once per run. The record is durable, so the report does not repeat for the rest of the job's life
What you see	An Exceeded Max Run Time badge beside the job's status on the Processes jobs list and in the job detail panel, which stays visible after the job finishes, and a Max Run Time Exceeded row on the detail panel's Summary tab giving the detection time. See Processes and runtime
What it raises	The Exceeded Max Runtime notification trigger, and any job event whose trigger is exceededMaxRuntime
When the record clears	On a recurring restart, and on an operator Restart. A new run starts with a clean record

tip

To have an overrunning job killed, attach a $JOB:KILL event to the trigger

The platform deliberately never kills the job itself, because for most jobs the useful answer is to be told rather than to lose the work in progress. Configure a job event with the exceededMaxRuntime trigger and a $JOB:KILL command if you want the stronger behavior — that is the opt-in stop path, and it is the same mechanism you would use for any other outcome.

note

$JOB STATUS in an event fired by an overrun reads the job's real status

A job event that fires on exceededMaxRuntime fires while the job is still running, so a $JOB STATUS token in its command renders JOB_RUNNING — not the condition that fired it. The condition is not a status and has no status to render.

Failure retries

Failure retries now actually retry. A job configured to retry after a failure never made a second attempt in earlier builds — the attempts and the interval were authored, stored and carried through deployment, the job failed once, and that was the end of it. The Retry Count on the job never moved either. Both work now, so a retry configuration you set up in the past and concluded was inert is live.

Maximum Attempts counts retries, not runs. A job with Maximum Attempts of 3 can run four times: its first run and three more. Minutes Between Attempts is the gap before each retry, and 0 means the next scheduling pass takes it.

A job that fails while it still has budget left is not written FAILED. It returns to WAIT_START_TIME carrying the time its next attempt is due, and its retry count goes up by one. While it waits there:

• Its dependents are not released, and no Failed event fires. A non-final attempt is not the job's outcome, so nothing downstream reacts to it — including a failure-triggered recovery job.
• The failed attempt's exit code and termination description stay on the job, so you can see why the last attempt failed. They are cleared when the next attempt starts, not when it is scheduled.
• Resources it held are released for the length of the wait, and taken again for the next attempt.
• A Workflow Container's sub-workflow is reset before the next attempt, exactly as it is for a recurring cycle's next run.

The pending attempt survives a platform restart. Holding the job and then releasing it resumes the attempt it was already waiting for rather than starting a fresh run.

The attempt itself re-enters the ordinary waiting sequence — its job, threshold, resource and expression dependencies, any conflict, and its agent's availability all apply again. Its start-time window is not re-applied, because the job has already started once.

The budget is per successful run. The retry count returns to zero when the job finishes OK (including Mark Finished OK) and at no other time — not on Mark Fixed, and not when a recurring cycle fails, so a cycle that spends retries carries the spent count into the next one. An operator Restart resets it only because Reset Retry Count is selected by default in the restart dialog; clearing that check box restarts the job with its spent count intact. Restart and Force Start both discard any attempt the job was waiting for.

The job detail panel's Summary tab shows Retry Count as used-of-maximum, so a job on its second of three retries reads 2 / 3.

When a retry is refused

A failure is written terminal — with no further attempt — in all of these cases:

The job…	Why no retry
was marked failed by a user (MARKED_FAILED)	A person's verdict on the job is not a run failure.
was killed	A retry would undo the action the operator took.
never ran — a Workflow Container whose setup failed: a missing or undeployable workflow reference, a circular reference, the nesting-depth cap, or a failed nested build	Every one of those is deterministic, so another attempt cannot come out differently. The job is already FAILED by the time retries are considered.
has retries disabled, or enabled with no attempt count	There is no budget to spend.
has spent its budget	Retry Count has reached Maximum Attempts.
would take its next attempt after its Latest Start Offset	The attempt could not legally start, so the job fails now rather than waiting to fail later.

The latest-start deadline binds a waiting retry and a started one differently

A job waiting for its next attempt when the deadline passes ends FAILED — it ran and it failed, so it earns that status, its Failed event, and the release of its failure/any dependents. A job whose retry has already started and is queued for dispatch or held behind a conflict when the deadline passes ends MISSED_START_TIME, exactly as a first run would. Both are intended.

Success reruns

Success reruns now actually run. A job configured to rerun after finishing OK — either mode — never restarted in earlier builds: the setting was authored, stored and carried through deployment, and the running job never saw it. Configure it and it takes effect. If you set this up in the past and concluded it did nothing, check it now.

Two consequences of it becoming live are worth knowing before you rely on it:

• Marking a recurring job Finished OK restarts it, rather than releasing its dependents. That is the rerun doing what it was configured to do; it just could not happen before.
• A workflow holding a recurring job does not complete while that job still has runs left in its cycle.

Each restart clears the job's start and end times rather than leaving the previous run's showing, so the times you see on a recurring job belong to its current run.

Action on overlap

Action on overlap decides what a recurringInstances job does when a run takes long enough that one or more of its configured instance times have already passed:

Setting	What happens
On completion (the default)	The next configured time fires immediately when the current run finishes, even though that time has already elapsed.
Skip	The already-elapsed times are passed over, and the job's next run lands on the next configured time still in the future.

Leaving it unset behaves as On completion. Earlier builds displayed Skip as the default while behaving as On completion; the two agree now, and the authoring default reads On completion.

Instance times are read in chronological order regardless of the order they were authored in, so Skip walks forward through them predictably.

Action on overlap applies to recurringInstances only and is rejected on the other modes. It has no meaning for restartOffset: an offset measured from the end of the previous run can never land in the past, and for one measured from the start there is no single defensible answer to how many intervals to skip — so nothing is invented there.

Editing reruns on a running job

A rerun configuration belongs to the workflow definition, not to a live instance. The Frequencies tab is read-only in instance scope, and the API rejects a change to a job instance's rerun configuration. Change it on the definition and deploy, and the next build picks it up.

note

How a run window interacts with success reruns is settled behavior now, and the two ends of the window answer differently — see Recurring jobs and the latest-start deadline.

What the build leaves out

A disabled job is left out before frequencies are looked at. The Disabled switch on a job takes it out of every build of the workflow — scheduled, automatic, and a container's build of a sub-workflow alike — without its frequencies being consulted at all. A workflow whose every job is disabled does not build. See A disabled job is left out of the build for what its dependents see and why an operator can still add it by hand.

Two frequency cases also don't behave like "the pattern matched, so the job is in the run".

On Request frequencies are excluded from every build. A job whose matching frequency is On Request is never selected by a scheduled or manual build; an operator adds it to an instance that already exists. A build that finds nothing else qualifying therefore fails and creates no instance — it does not create an empty one for those jobs to be added into. If you need an instance to exist, give the workflow at least one job on a scheduling frequency.

toBeSkipped no longer skips the job's own gates. A job whose winning frequency carries build status toBeSkipped is built as a deferred skip (JOB_TO_BE_SKIPPED), not as an already-finished SKIPPED job. The mark resolves to terminal SKIPPED only once the job's own TIME, JOB (dependency), THRESHOLD and RESOURCE gates are satisfied — the same mechanism an operator's manual Skip uses.

That matters for what downstream jobs see. Previously the job was created terminal, so its dependents were released immediately and could complete even when the predecessor they actually depended on had failed. Now the skip waits its turn, and a mark whose gates never open parks indefinitely rather than letting the workflow complete past it. A workflow sitting on a JOB_TO_BE_SKIPPED job is therefore waiting on that job's dependencies, not stuck on the skip itself. See Job and workflow statuses.

Troubleshooting

Symptom	Likely cause	Resolution
A job didn't appear in the day's run	The job's Disabled switch is on, its frequency didn't match the date, the day is excluded by a calendar/working-days rule, its frequency is On Request, or its build status is doNotSchedule/disabled	Check the job's Disabled switch first, then its frequency, calendar, and build status (Builder).
A job appears but sits at JOB_TO_BE_SKIPPED	Its build status is toBeSkipped, and the skip is waiting on the job's own dependency/threshold/resource/time gates	Expected. Resolve what the job is waiting on, or skip/cancel it explicitly (Operator).
The whole workflow didn't build	The automatic daily build isn't enabled for the environment, the workflow has no build settings, or nothing qualified — including a workflow whose only eligible work is On Request	Confirm the build settings and that at least one job qualifies, or start the build yourself (Builder / Operator).
Nothing is built automatically, for any workflow	The daily build sweep is off — it's disabled by default	Have it enabled for the environment once the workflows' build settings there have been reviewed (Administrator).
One workflow is skipped by the automatic build while others build	Its dates fall outside the deployment window, it's a sub-workflow, or a build setting can't be read as a number or a boolean — often a deployment transformation rule that wrote an unusable value	Check the deployment's effective/expiration dates and any transformation rule targeting autoBuildSettings (Builder).
A date already has a COMPLETED or CANCELLED instance and the automatic build won't replace it	Expected — an unattended rebuild never replaces a terminal instance	Rebuild it yourself if that's genuinely what you want (Operator).
The automatic build won't replace a date whose instance is only held or waiting to start	The instance has already started running at some point — held part-way through, or reopened from COMPLETED. An unattended rebuild leaves any already-started instance alone whatever its current status	Rebuild it yourself if you do want the date re-run from scratch (Operator).
A recurring job fires an instance time that has already passed	Action on overlap is On completion, which is the default	Set it to Skip to wait for the next future time instead (Builder).
Workflow built but nothing runs	Built on hold (buildOnHold)	Release it when ready — it's not stuck (Operator).
Job flagged LateToStart / LateToFinish	The job passed its configured offset	Expected signal; investigate why the job started/finished late (Operator).
A job overran its Max Run Time and nothing was reported	The limit never reached the built job — only a hand-edited job instance carried one	Fixed: the frequency's limit is now carried onto every built job. Re-check the limit on a fresh run, and see Exceeding Max Run Time (Builder).
A job shows Exceeded Max Run Time but is still running, and its status is unchanged	Expected — the overrun is a label, not a status, and the platform does not stop the job	Attach a $JOB:KILL job event to the exceededMaxRuntime trigger if you want it stopped (Builder).
An Exceeded Max Runtime notification or job event never arrives, though the badge is there	The notification trigger isn't enabled, or no job event is configured on exceededMaxRuntime	Both are opt-in. Enable the trigger on the notification group, or add the job event (Administrator / Builder).
Job keeps retrying or rerunning	failureRetries or successReruns configured	Confirm the retry/rerun settings match intent (Builder). Both only started taking effect in recent builds — success reruns first, failure retries now — so a configuration that looked inert before is live. Remember that Maximum Attempts counts retries, so 3 means up to four runs.
A failed job sits in WAIT_START_TIME instead of going FAILED, and its dependents are still waiting	It has retry budget left and is waiting for its next attempt	Expected. Check Retry Count on the job's Summary tab; the exit code shown is the last attempt's. Restart or cancel it if you do not want the remaining attempts (Operator).
Old instances build up and are never removed	Expected — deleteAfterDays is stored but not acted on, and nothing removes instances automatically	Delete instances you no longer need from Processes (Operator).
Scheduling a workflow from Processes fails with Internal server error	One cause is a calendar the workflow or one of its frequencies names can't be resolved — see Holiday calendars now reach the build	Check the workflow's Additional Holiday Calendar and each frequency's exclusion calendar still exist, then schedule again (Builder / Operator).
A job started after its Latest Start	It was still waiting at a dependency, threshold, resource, expression or agent gate when the deadline passed — the deadline is not checked there	See Where the deadline is checked. Hold or cancel the job if a late start must not happen (Operator).
A build refuses with an unknown or blank instance name, or an identity conflict	The workflow has Allow Multi-Instance on and the build's instance target doesn't resolve	See Schedule instances (Operator).

Contact support when

• A job's frequency, calendar, working days, and build status all indicate it should build, but it does not appear in the run.

Include the workflow, the job, its frequency/calendar settings, and the build date in question.