Workflow Scheduling, Execution, and Worker Management
Scheduling mechanics
Schedules are owned by users and executed by the controller, which queues runs and dispatches them to available workers. Know the schedule types: time-based (recurring intervals), run-once, and triggered schedules (event-driven). The controller maintains the queue; workers pull assignments. Concurrency is bounded by worker engine settings, so a busy worker delays queued jobs.
Execution lifecycle
A run moves through states: queued, running, completed, failed, canceled. Results (outputs, logs) are stored and surfaced in the Gallery. Know that a failed run does not automatically retry unless configured, and that schedule ownership affects who can edit or delete it (owner or Curator).
Worker management
Workers can be dedicated to specific queues or shared across the pool. Understand worker tags/queues: assigning a workflow to a worker queue routes it to workers with that capability. If no worker matches the queue, the job waits indefinitely. Workers must be healthy and version-matched to the controller.
Traps
Common traps: assuming schedules run as the person who last edited the workflow (they run under the schedule owner's context/credentials); assuming a canceled job frees the worker instantly; and assuming adding workers automatically speeds a single long workflow (it does not - one workflow runs on one worker unless designed to parallelize). Also watch for time zone confusion in schedule definitions.
Worked example
A nightly job is stuck "queued." Diagnose: is a worker online, version-matched, and assigned to the required queue? Is concurrency maxed by a long-running job? Fix by adding a worker to the queue or reducing concurrent load - not by re-saving the schedule.
Rule of thumb
Queued-but-not-running almost always means no eligible worker (offline, wrong queue, or at concurrency limit).